Вопросы Теги

Призрачный пинг в системе Linux с несколькими сетевыми картами

У меня есть система Linux с 3 сетевыми адаптерами, и все 3 находятся в одной подсети. Я настроил маршрутизацию политики в системе с правилами IP и маршрутами IP с использованием 3 таблиц. Это IP-адреса трех сетевых адаптеров.

ETH0: 192.168.1.10

ETH1: 192.168.1.11

ETH2: 192.168.1.12

Я заметил одну вещь: если кабели к ETH1 & ETH2 отключены, пинг на их IP-адреса с ПК, подключенного к ETH0 через коммутатор, иногда может быть успешным.

Я понимаю, что это является следствием наличия IP-адресов в одной подсети (хотя, разве нельзя этого избежать, когда я использую правила IP?), Но я не понимаю, как коммутатор может успешно маршрутизировать пакеты, предназначенные для IP, принадлежащего ETH1 или ETH2, на IP, предназначенный для ETH0? Другими словами, как пакет, предназначенный для 192.169.1.12, может быть отправлен коммутатором на 192.168.1.10? Разве в его внутренней таблице маршрутизации нет записи только для 192.168.1.10, а не для двух других IP-адресов, потому что их кабели отключены?

0
задан 7 March 2018 в 07:19
1 ответ

Речь идет не только о маршрутизации (уровень 3), но и о ARP (связывает уровни 2 и 3). Linux обычно отвечает на все запросы ARP одним и тем же MAC, это означает, что одноранговые узлы будут иметь только один MAC-адрес в своем кэше ARP для 3 IP-адресов и достигнут только одной карты. Возможно, что иногда выбранный MAC будет изменяться, вызывая всевозможные проблемы.

Есть доступная функция для предотвращения этого. Это параметр arp_filter , но он также требует нескольких правил маршрутизации (для каждого IP и / или интерфейса). Использование только arp_filter или только таблиц маршрутизации может дать худшие результаты, чем их полное отсутствие.Оба нужны вместе. Поскольку OP не показывал, какие политики маршрутизации использовались, я поместил ниже полное решение, учитывая, что не было никаких специальных политик маршрутизации. Значения для таблиц маршрутизации (100, 101, 102) были выбраны случайным образом.

  • LAN

    • попробовать перед: 

       ip route получить 192.168.1.1 из 192.168.1.10
ip route получить 192.168.1.1 из 192.168.1.11
ip route получить 192.168.1.1 из 192.168.1.12

      Обратите внимание на результаты: все используют одну и ту же карту (это не значит, что в любом случае так происходит всегда).
      На одноранговом сервере в той же локальной сети, как можно быстрее: 

       ping -c1 192.168.1.10 &
пинг -c1 192.168.1.11 и
пинг -c1 192.168.1.12
ip neigh показать на 192.168.1.10
ip neigh показать на 192.168.1.11
ip neigh показать на 192.168.1.12

      наверняка все 3 IP-адреса разрешаются на один и тот же MAC-адрес, поэтому карта: единственная карта, которая будет получать трафик от этого узла.

    • измените настройки (Предупреждение: риск потери подключения): 

       echo 1> /  процесс / система / сеть / ipv4 / конф / eth0 / arp_filter
эхо 1> / proc / sys / net / ipv4 / conf / eth1 / arp_filter
эхо 1> / proc / sys / net / ipv4 / conf / eth2 / arp_filter

ip route добавить 192.168.1.0/24 dev eth0 таблица 100
ip route добавить 192.168.1.0/24 dev eth1 таблица 101
ip route добавить 192.168.1.0/24 dev eth2 таблица 102

ip правило добавить из поиска 192.168.1.10 100
ip правило добавить из поиска 192.168.1.11 101
ip правило добавить из поиска 192.168.1.12 102

    • очищает кэши ARP одноранговых узлов (запросы DAD дублируются как GARP ) для ускорения восстановления, если это необходимо. Не требуется во время загрузки, так как таких кешей не было. Используйте arping iputils, а не автономный инструмент arping (RHEL: iputils , Debian: iputils-arping , а не пакет arping ), поскольку синтаксис отличается. 

       arping -c5 -s 192.168.1.10 -D 192.168.1.10 -I eth0 &
arping -c5 -s 192.168.1.11 -D 192.168.1.11 -I eth1 &
arping -c5 -s 192.168.1.12 -D 192.168.1.12 -I eth2 &

    • повторите предыдущие проверки и сравните: все должно быть, как ожидалось, а таблицы соседей на одноранговых серверах должны показывать один другой MAC-адрес для каждого IP-адреса, соответствующий MAC-адресу правильной карты.

  • WAN

    Маршрут по умолчанию будет по-прежнему использовать "default" настройки из таблицы main , скорее всего, с использованием eth0. Этот маршрут необходимо продублировать в каждой таблице. Предполагая, что маршрутизатор по умолчанию - 192.168.1.1 (иначе, отрегулируйте), это будет: 

     ip route добавить значение по умолчанию через 192.168.1.1 dev eth0 table 100
ip route добавить по умолчанию через 192.168.1.1 dev eth1 table 101
ip route добавить по умолчанию через 192.168.1.1 dev eth2 table 102

Теперь, если кабель отключен, произойдет ожидаемый результат: IP-адрес, установленный на соответствующей сетевой карте, станет недоступным в 100% случаев.

1
ответ дан 4 December 2019 в 16:00

Теги

Похожие вопросы