Я считаю, что получил таблицу, которая маршрутизирует пакеты от и до eth1 / 192.168.3.x через 192.168.3.1, и пакеты от и до eth0 / 192.168.1.x через 192.168.1.1 (полезный источник).
Вопрос: при выполнении трассировки из 192.168.3.20 (изнутри vserver) я получаю kernel: [318535.927489] martian source 192.168.3.20 from 212.47.223.33, on dev eth0 на целевом IP или рядом с ним, в то время как промежуточные переходы отсутствуют (журнал ниже).
Я не понимаю, почему этот пакет приходит на eth0, а не на eth1, даже после прочтения этого:
Обратите внимание, что вы можете видеть пакеты с немаршрутизируемых IP-адресов при выполнении команд traceroute или tracepath. Хотя пакеты не могут быть маршрутизированы на эти маршрутизаторы, для пакетов, отправленных между двумя маршрутизаторами, необходимо знать только адрес следующего перехода в локальных сетях, который может быть немаршрутизируемым адресом.
Может ли кто-нибудь объяснить этот абзац на человеческом языке? Судя по коротким первоначальным испытаниям, все остальное работает, не вызывая марсиан. Связано ли это с характером операции трассировки пути или у меня есть другая более серьезная проблема с маршрутизацией, которая приведет к прерыванию рабочего трафика?
Боковое примечание: можно ли проверить марсианский пакет с помощью tcpdump или wirehark или чего-нибудь в этом роде? Мне не удалось заставить его появиться самостоятельно.
vserver-20 / # tracepath -n 212.47.223.33
1: 192.168.3.2 0.064ms pmtu 1500
1: 192.168.3.1 1.076ms
1: 192.168.3.1 1.259ms
2: 90.191.8.2 1.908ms
3: 90.190.134.194 2.595ms
4: 194.126.123.94 2.136ms asymm 5
5: 195.250.170.22 2.266ms asymm 6
6: 212.47.201.86 2.390ms asymm 7
7: no reply
8: no reply
9: no reply
^C
Маршрутизация хоста:
$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:24:1d:de:b3:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:46:46:a3:6a brd ff:ff:ff:ff:ff:ff
inet 192.168.3.2/27 scope global eth1
inet 192.168.3.20/27 brd 192.168.3.31 scope global secondary eth1 # linux-vserver instance
$ sudo ip route
default via 192.168.1.1 dev eth0 metric 3
unreachable 127.0.0.0/8 scope host
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
192.168.3.0/27 dev eth1 proto kernel scope link src 192.168.3.2
$ sudo ip rule
0: from all lookup local
32764: from all to 192.168.3.0/27 lookup dmz
32765: from 192.168.3.0/27 lookup dmz
32766: from all lookup main
32767: from all lookup default
$ sudo ip route show table dmz
default via 192.168.3.1 dev eth1 metric 4
192.168.3.0/27 dev eth1 scope link metric 4
Маршрутизация шлюза
# ip route
10.24.0.2 dev tun0 proto kernel scope link src 10.24.0.1
10.24.0.0/24 via 10.24.0.2 dev tun0
192.168.3.0/24 dev br-dmz proto kernel scope link src 192.168.3.1
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
$ISP_NET/23 dev eth0.1 proto kernel scope link src $WAN_IP
default via $ISP_GW dev eth0.1
Дополнительная информация
Варианты изоляции невиртуализированного сетевого интерфейса?
Я считаю, что «проблема» в том, что оба ваших интерфейса подключены к одной сети. В какой-то момент вы получаете пакеты с исходным IP 192.168.3.20 на вашем интерфейсе eth0, что приводит к тому, что запись конфигурации log_martians поступает в actino.
Я почти уверен, что у вас включен rp_filter, и что он исчезнет, если вы его отключите (например, / proc / sys / net / ipv4 / conf / all / rp_filter), но прочтите ниже:
Это может быть по двум причинам:
Есть несколько способов решить эту проблему, и да, вы можете использовать tcpdump для этого (например, tcpdump -ni eth0 'host 192.168.3.20').
Если вы получите марсианский пакет, Wireshark сможет его показать.
Я также вижу, что вы отключили loopback, установив недостижимый маршрут для 127.0.0.0/8. Это не соответствует стандартам и, вероятно, бесполезно, но я сомневаюсь, что это имеет какое-то отношение к этой проблеме.
Параграф документации просто означает, что вы, вероятно, увидите адреса RFC1918 или другие недостижимые вещи в traceroute, поскольку эти адреса могут использоваться между маршрутизаторами во многих случаях (например, в пределах одной AS), но это будет адрес, который маршрутизатор выдает, когда пакет превышает свой TTL там. Это не значит, что вам следует ожидать марсиан. Я также сомневаюсь, что это как-то связано с этим конкретным пакетом.
Марсианский пакет может не иметь ничего общего с трассировкой маршрута. Однако может. Это часто вызвано тем, что шлюз не выполняет исходный nat, когда это должно быть, но также возможно, что у вас где-то нарушено правило NAT, транслирующее адрес назначения пакетов, исходящих от eth1, на IP-адрес eth0. Это наиболее вероятно с учетом источника пакета. Это также может означать, что вы забываете выполнять NAT источника для исходящих пакетов на вашем шлюзе.
Вам следует запустить захват Wirehark на обоих eth1 и eth0, и попытаться найти пакет в eth0 и посмотреть, сможете ли вы сопоставить его с пакетом из eth1. Также проверьте свои правила NAT.
Могу ответить на ваш промежуточный вопрос. У меня есть / 29, из которого я маршрутизирую каждый / 32 независимо:
ip route add 8.4.3.3/32 via 192.168.17.33.
Таким образом, я могу использовать все восемь/32 вместо потери одного для широковещательного адреса, а другого для интерфейса маршрутизатора в этой подсети.
Что касается неправильного интерфейса; можешь показать свои правила NAT? Спасибо бы:
iptables -vnL -t nat