Этот вопрос похож на многие другие, с которыми я консультировался при поиске ответа, как на ServerFault, так и в других местах, но я застрял, потому что, насколько я вижу, я настроил это правильно, но мне не доставляет радости его получать работает.
Я создал смоделированную среду с использованием нескольких машин в VirtualBox, один представляет собой сервер (который будет использоваться в качестве маршрутизатора), другой моделирует два модема ADSL (просто ведет себя как NAT-маршрутизатор с двумя портами на стороне LAN и один на стороне WAN. в Интернет).
Сервер (SRV) соединяет два порта (ETH2 и ETH3) с двумя отдельными виртуальными сетями Vbox через машину ADSL (подключаясь к его портам ETH2 / 3 соответственно).
+----------+
| SRV |
+----------+
ETH2 (192.168.1.10) | | ETH3 (192.168.2.11)
| |
| |
ETH2 (192.168.1.1) | | ETH3 (192.168.2.1)
+----------+
| ADSL |
+----------+
Порты ADSL - ETH2 (192.168.1.1) и ETH3 (192.168.2.1).
Порты SRV - ETH2 (192.168.1.10) и ETH3 (192.168.2.11).
SRV iptables не делать ничего интересного, кроме см. комментарии ниже к настройкам main маршрут по умолчанию во время тестирования.
ip route show
default via 192.168.1.1 dev eth2
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.10
192.168.2.0/24 dev eth3 proto kernel scope link src 192.168.2.11
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.1
192.168.13.0/24 dev admin.tinc proto kernel scope link src 192.168.13.1
Установить две таблицы adsl1 и ads2
ip route show table adsl1
default via 192.168.1.1 dev eth2
192.168.1.0/24 dev eth2 scope link src 192.168.1.10
ip route show table adsl2
default via 192.168.2.1 dev eth3
192.168.2.0/24 dev eth3 scope link src 192.168.2.11
ip rule
0: from all lookup local
32762: from all to 192.168.1.0/24 lookup adsl1
32763: from all to 192.168.2.0/24 lookup adsl2
32764: from 192.168.2.0/24 lookup adsl2
32765: from 192.168.1.0/24 lookup adsl1
32766: from all lookup main
32767: from all lookup default
Если я пингую через ETH2, проблем нет.
ping -I eth2 -c 1 google.com
PING google.com (216.58.214.14) from 192.168.1.10 eth2: 56(84) bytes of
data.
64 bytes from lhr26s05-in-f14.1e100.net (216.58.214.14): icmp_seq=1 ttl=61
time=20.2 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.288/20.288/20.288/0.000 ms
Если я пингую через ETH3, трафик на ETH3 вообще отсутствует.
PING google.com (216.58.213.110) from 192.168.2.11 eth3: 56(84) bytes of
data.
--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Если я изменю main таблица шлюз по умолчанию ...
ip route replace default via 192.168.2.1 dev eth3
происходит обратное (ETH3 работает, ETH2 не работает). На мой взгляд, это предполагает таблицы маршрутизации adsl1 и adsl2 либо ошибаются, либо просто не рассматриваются (неправильные правила). Но я не могу понять почему?
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth2.rp_filter=0
sysctl -w net.ipv4.conf.eth2.rp_filter=0
Повторяется ping -I eth3 google.com пока...
tcpdump -i eth3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
20:26:32.207178 ARP, Request who-has lhr35s11-in-f14.1e100.net tell 192.168.2.11, length 28
20:26:33.221587 ARP, Request who-has lhr35s11-in-f14.1e100.net tell 192.168.2.11, length 28
Когда ETH3 установлен в качестве маршрута по умолчанию в main (без других изменений) tcpdump является:
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
21:41:51.865488 IP (tos 0x0, ttl 64, id 31173, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.2.11 > google-public-dns-a.google.com: ICMP echo request, id 2962, seq 1, length 64
21:41:51.866542 IP (tos 0x0, ttl 64, id 18679, offset 0, flags [DF], proto UDP (17), length 71)
192.168.2.11.36067 > one.one.one.one.domain: [bad udp cksum 0xc4f9 -> 0xb220!] 31965+ PTR? 11.2.168.192.in-addr.arpa. (43)
21:41:51.885947 IP (tos 0x0, ttl 61, id 4776, offset 0, flags [DF], proto ICMP (1), length 84)
google-public-dns-a.google.com > 192.168.2.11: ICMP echo reply, id 2962, seq 1, length 64
ip route get 8.8.8.8 oif eth3
8.8.8.8 dev eth3 src 192.168.2.11
cache users 1
Так что определенно что-то повреждено с маршрутизацией (а не проблемами где-то еще). Также объясняет исключительное присутствие ARP!
Ладно!
Мне кажется, что когда трафик направляется на интерфейс ETH3, ему не назначается адрес отправителя 192.168.2.11 как я ожидаю, по крайней мере, не вовремя для решения db политики маршрутизации.
Я вручную добавил простое правило:
ip rule add to 8.8.8.8 lookup adsl2
затем
ip route get 8.8.8.8 oif eth3
8.8.8.8 via 192.168.2.1 dev eth3 table adsl2 src 192.168.2.11
cache
Очевидно таблица adsl2 используется и правильно устанавливает via 192.168.2.1. Ура!
НО если я заменю это правило более конкретным правилом
ip rule add to 8.8.8.8 from 192.168.2.11 lookup adsl2
я получил
ip route get 8.8.8.8 oif eth3
8.8.8.8 dev eth3 src 192.168.2.11
cache
Вернуться к состоянию, где via не устанавливается, вывод: adsl2 таблица не используется. Дальнейший вывод: from не эффективно, поэтому интерфейс eth3 не устанавливает адрес src на 192.168.2.11 несмотря ip a показывая
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:e5:7e:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.2.11/24 brd 192.168.2.255 scope global eth3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fee5:7eeb/64 scope link
valid_lft forever preferred_lft forever
Где я облажался?