Я пытаюсь использовать Ubuntu в качестве шлюза для моей локальной сети. Это моя установка:
net.ipv4.conf.ip_forward был включен на шлюзе Ubuntu. На шлюзе действуют следующие правила iptables:
iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
iptables -A FORWARD -i ens4 -j ACCEPT
Таблица маршрутизации шлюза:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.10.161 0.0.0.0 UG 0 0 0 ens3
10.0.10.160 0.0.0.0 255.255.255.224 U 0 0 0 ens3
10.0.10.224 0.0.0.0 255.255.255.224 U 0 0 0 ens4
169.254.169.254 10.0.10.161 255.255.255.255 UGH 0 0 0 ens3
Таблица маршрутизации клиента:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.10.231 0.0.0.0 UG 0 0 0 ens3
10.0.10.224 0.0.0.0 255.255.255.224 U 100 0 0 ens3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 ens3
169.254.169.254 10.0.10.225 255.255.255.255 UGH 100 0 0 ens3
Обе машины могут пинговать друг друга, поэтому нет проблем с подключением к локальной сети между ними. Однако, если я попытаюсь выполнить пинг, например, 8.8.8.8 от клиента, он показывает 100% потерю пакетов, а tcpdump на интерфейсе LAN не показывает ответов ping. Тем не менее, если я сделаю tcpdump на шлюзе, он покажет как эхо-запрос от клиента, так и эхо-ответ:
user@snort-id:~$ sudo tcpdump -i ens4 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
13:33:08.503943 IP 10.0.10.238 > google-public-dns-a.google.com: ICMP echo request, id 4424, seq 1, length 64
13:33:08.507787 IP google-public-dns-a.google.com > 10.0.10.238: ICMP echo reply, id 4424, seq 1, length 64
13:33:09.526402 IP 10.0.10.238 > google-public-dns-a.google.com: ICMP echo request, id 4424, seq 2, length 64
13:33:09.530203 IP google-public-dns-a.google.com > 10.0.10.238: ICMP echo reply, id 4424, seq 2, length 64
13:33:10.551124 IP 10.0.10.238 > google-public-dns-a.google.com: ICMP echo request, id 4424, seq 3, length 64
13:33:10.554807 IP google-public-dns-a.google.com > 10.0.10.238: ICMP echo reply, id 4424, seq 3, length 64
Так что просто из tcpdump похоже, что пересылка работает. Однако клиент не получает ответа. Я не уверен, что это важно, но и шлюз, и клиент работают на OpenStack.
Был бы очень признателен за любую помощь в этом.
Изменить: по запросу:
Вывод iptables шлюза:
user@snort-id:~$ sudo iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 541 packets, 37916 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 9 packets, 840 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 43 packets, 33087 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 23 packets, 31668 bytes)
pkts bytes target prot opt in out source destination
493 31309 MASQUERADE all -- * ens3 0.0.0.0/0 0.0.0.0/0
user@snort-id:~$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 1938 packets, 132K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 1754 packets, 238K bytes)
pkts bytes target prot opt in out source destination
1754 110K ACCEPT all -- ens4 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 1250 packets, 168K bytes)
pkts bytes target prot opt in out source destination
Обе iptables -t nat -vnL и iptables -vnL не показывать правил на клиенте.
Что ж, похоже, я ошибался в том, что OpenStack (в моем случае Devstack) не вызывает проблемы. По умолчанию Devstack использует некоторые меры по борьбе с IP и Mac-спуфингом. Для этого он создает правила iptables на хосте Devstack, которые вызывают отбрасывание пакетов ответа от шлюза к клиенту. Чтобы исправить это, я добавил следующие строки в свой стек разработчика local.conf
Q_USE_SECGROUP=False
[[post-config|$NOVA_CONF]]
[DEFAULT]
security_group_api=nova
firewall_driver=nova.virt.firewall.NoopFirewallDriver
Обратите внимание, что это по существу отключает весь брандмауэр.