Ping через таблицу маршрутизации linux не работает [или] как это ожидается?
длинный вопрос, короче:
Ping over
r1-r4-r2путь работает с помощью10.0.1.*или10.0.2.*IP-адреса, но не удается, если мы изменим путь кr1-r3-r2используя1.0.0.*или1.0.1.*IP-адреса для точно таких же пакетов (за исключением того, что пакеты'srcиdstполя IP изменяются с10.*to1.*и обратно вs1иs2соответственно). Почему?
вопрос в деталь:
у меня небольшая топология, как показано ниже
h1 -- s1 -- r1 -- r4 -- r2 -- s2 -- h2
/
/
/
r3
на sявляются экземплярами OpenvSwitch в то время как rявляются Ubuntu 16 Linux машины.
IP-адреса:
h1-eth0 - 10.0.1.10/24
s1 - 10.0.1.50/24
h2-eth0 - 10.0.2.10/24
s2 - 10.0.2.50/24
r1-eth0 - 10.0.1.1/24
r1-eth1 - 10.0.11.2/24
r1-eth2 - 10.0.12.2/24
r2-eth0 - 10.0.2.1/24
r2-eth1 - 10.0.13.1/24
r2-eth2 - 10.0.5.1/24
r3-eth0 - 10.0.12.1/24
r3-eth1 - 10.0.5.2/24
r4-eth0 - 10.0.11.1/24
r4-eth1 - 10.0.13.2/24
как вы можете видеть, есть два похожих пути между r1 и r2. Я добавляю следующий static вступления.
r1
sudo ip route add 10.0.2.0/24 via 10.0.11.1
r2
sudo ip route add 10.0.1.0/24 via 10.0.13.2
r4
sudo ip route add 10.0.1.0/24 via 10.0.11.2
sudo ip route add 10.0.2.0/24 via 10.0.13.1
пинг между h1 и h2 работает так, как ожидалось. Теперь, поскольку коммутаторы являются OVS( и, следовательно, OpenFlow-enabled), я устанавливаю записи в s1 до сопоставьте IP-адреса назначения с другой подсетью.
т. е. IP 10.0.1.10 будет сопоставлен с 1.0.0.10 в то время как IP 10.0.2.10 будет сопоставлен с 1.0.1.10, когда такой пакет получен в s1, в то время как IP-адреса назначения будут сопоставлены с оригиналом в s2.
(я проверил, что эти записи действительно верны и работают так, как ожидалось. Также я добавил эту запись только для соответствия пакетам ICMP). Аналогичная процедура будет выполнена, когда ответ ping будет отправлен h1.
наряду с этим я устанавливаю статические маршруты в маршрутизаторах для маршрутизации этих ИПС.
r1
sudo ip route add 1.0.0.0/24 via 10.0.1.50
sudo ip route add 1.0.1.0/24 via 10.0.12.1
r2
sudo ip route add 1.0.0.0/24 via 10.0.5.2
sudo ip route add 1.0.1.0/24 via 10.0.2.50
r3
sudo ip route add 1.0.0.0/24 via 10.0.12.2
sudo ip route add 1.0.1.0/24 via 10.0.5.1
теперь, если я пингую h1 от h2, пакет начинается с IP-адреса назначения 10.0.1.10, который сопоставлен с 1.0.0.10 на s2, r2 маршрутизирует это и отправляет его в r3, R3 маршрутизирует его и отправляет в r1. но r1, даже после получения пакета на одном интерфейсе и наличия соответствующей записи в таблице маршрутизации Linux, не маршрутизирует и не перенаправляет пакет.
даже ip route get выводит правильный порт, на который пакет должен быть передан. Нет записей брандмауэра в ip tables как хорошо.
дополнительная информация:
если я изменю недавно добавленные записи маршрутизации, чтобы использовать исходный путь из
r1-r4-r2(т. е. мы маршрутизируем по этому пути с сопоставленными ip-адресами), он ведет себя так, как ожидалось, и пинг работает как ожидаемый.альтернативно, если я изменю старые записи маршрутизации для 10.0.2.0 / 24 в r1 и
10.0.1.0 / 24 в r2 (который теперь идеально даже не должен соответствовать новому пакеты в качестве IP-адресов назначения находятся в 1.0.0.* выбор или 1.0.1.* только) использовать новый путьr1-r3-r4вместе с этими сопоставленными пакетами IP, пинг между r2 и r1 работают как ожидалось.
детали, которые могут потребоваться:
финал таблицы маршрутизации следующие:
r1
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.11.1 0.0.0.0 UG 0 0 0 eth1
1.0.0.0 10.0.1.10 255.255.255.0 UG 0 0 0 eth0
1.0.1.0 10.0.12.1 255.255.255.0 UG 0 0 0 eth2
10.0.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
10.0.2.0 10.0.11.1 255.255.255.0 UG 0 0 0 eth1
10.0.11.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
10.0.12.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2
r2
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.13.2 0.0.0.0 UG 0 0 0 eth1
1.0.0.0 10.0.5.2 255.255.255.0 UG 0 0 0 eth1
1.0.1.0 10.0.2.50 255.255.255.0 UG 0 0 0 eth0
10.0.1.0 10.0.13.2 255.255.255.0 UG 0 0 0 eth1
10.0.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
10.0.5.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2
10.0.13.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
r3
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.5.1 0.0.0.0 UG 0 0 0 eth1
1.0.0.0 10.0.12.2 255.255.255.0 UG 0 0 0 eth0
1.0.1.0 10.0.5.1 255.255.255.0 UG 0 0 0 eth1
10.0.1.0 10.0.12.2 255.255.255.0 UG 0 0 0 eth0
10.0.2.0 10.0.5.1 255.255.255.0 U 1 0 0 eth1
10.0.5.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
10.0.12.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
r4
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth4
1.0.0.0 10.0.11.2 255.255.255.0 UG 0 0 0 eth0
1.0.1.0 10.0.13.1 255.255.255.0 UG 0 0 0 eth1
10.0.1.0 10.0.11.2 255.255.255.0 UG 0 0 0 eth0
10.0.2.0 10.0.13.1 255.255.255.0 UG 0 0 0 eth1
10.0.11.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
10.0.13.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth4
Примечание: 192.168.0.* подсеть, подключенная к внешнему интернету.
как вы думаете, в чем проблема ? Я совершенно сбит с толку, глядя на эту проблему.
3 ответов
поведение маршрутизации Linux здесь было ожидаемым.
флаг обратный путь фильтрации
т. е. /proc/sys/net/ipv4/conf/<interfacename>/rp_filter был включен (по умолчанию установлено значение 1).
фильтр обратного пути предоставляется в качестве функции безопасности ядра Linux. Общим примером является выход частного IP-пространства в интернет. Если у вас есть интерфейс с маршрутом 195.96.96.0 / 24 к нему, вы не ожидаете, что пакеты от 212.64.94.1 прибудут туда. Поэтому kernel отбрасывает такие пакет, если флаг установлен в 1.
более формально,
фильтрация обратного пути-это механизм, принятый ядром Linux для проверьте, является ли IP-адрес источника пакета, который был получено маршрутизируется.
другими словами, когда машина с фильтрацией обратного пути включена получает пакет, машина сперва проверит ли источник полученный пакет доступен через интерфейс, в котором он пришел.
- если он маршрутизируется через интерфейс, который он пришел, то машина примет пакет.
- если он не маршрутизируется через интерфейс, который он пришел, то машина отбросит этот пакет.
последние ядра предоставляют еще одно значение опции 2. Этот параметр немного более либерально с точки зрения принятия трафика.
если исходный адрес полученного пакета маршрутизируется через любой из интерфейсы машина, машина примет пакет.
во-первых, ваши детали топологии неполны, вам не хватает деталей r3 и r4, но их можно вывести.
вместо того, чтобы устранить проблему, я просто пытаюсь объяснить, что должно произойти. Однако было бы намного проще, если бы вы просто использовали протокол маршрутизации, такой как OSPF, который разработан, чтобы сделать это легко, поэтому вам не нужно делать это вручную.
каждое устройство, которое маршрутизирует, должно знать, как добраться до каждой другой подсети, если она должна быть доступный. Это означает, что вы можете либо добавить маршруты по умолчанию (т. е. маршруты, соответствующие 0.0.0.0/0), либо ввести в каждую подсеть соответствующий next-ip в каждый маршрутизатор (см. ниже). Обычно вам не нужно добавлять маршруты для подсетей, которые подключены (т. е. у вас есть ip на этом маршрутизаторе в этой подсети)
R1 маршруты
10.0.13.0/24 -> 10.0.11.1
10.0.5.0/24 -> 10.0.11.1
10.0.2.0/24 -> 10.0.11.1
R2 маршруты
10.0.1.0/24 -> 10.0.13.2
10.0.12.0/24 -> 10.0.13.2
10.0.11.0/24 -> 10.0.13.2
R3 маршруты
10.0.1.0/24 -> 10.0.12.2
10.0.11.0/24 -> 10.0.12.2
10.0.13.0/24 -> 10.0.5.1
10.0.2.0/24 -> 10.0.5.1
R4 Маршруты
10.0.1.0/24 -> 10.0.11.2
10.0.12.0/24 -> 10.0.11.2
10.0.2.0/24 -> 10.0.13.1
10.0.5.0/24 -> 10.0.13.1
для устройств H1, S1, H2 и S2 они должны иметь маршрут по умолчанию, который указывает на шлюз 10.0.1.1 и 10.0.2.1.
чтобы сделать эту работу, используйте это на всех машинах:
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
> echo 0 > $i
> done
или сделайте следующую запись в своем /etc/sysctl.conf
net.ipv4.conf.all.rp_filter = 0
rp_filter будет фильтровать пакеты в трех режимах: 0 отключено, 1 строго и 2 свободно.
пример
Client A - 192.168.2.10 - connected to router via eth0
Router
eth0 - 192.168.2.150
routes - 192.168.2.0/24
eth1 - 10.42.43.1
routes - 10.42.43.0/24
Примечание: нет маршрута по умолчанию
Client C - 10.42.43.50 - connected to router via eth1
С этой настройкой и rp_filter на маршрутизаторе, установленном в "свободный режим" (2), пакет на eth0 от 1.2.3.4 до 10.42.43.50 будет блокированный.
С rp_filter на маршрутизаторе установлен в "строгий режим" (1) пакет на eth0 от исходного адреса 10.42.43.2 будет заблокирован.
когда установлено значение "отключено" (0), оба пакета пройдут.