Назад | Перейти на главную страницу

Призрачный пинг в системе 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-адресов, потому что их кабели отключены?

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

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

  • LAN

    • попробуйте раньше:

      ip route get 192.168.1.1 from 192.168.1.10
      ip route get 192.168.1.1 from 192.168.1.11
      ip route get 192.168.1.1 from 192.168.1.12
      

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

      ping -c1 192.168.1.10 &
      ping -c1 192.168.1.11 &
      ping -c1 192.168.1.12
      ip neigh show to 192.168.1.10
      ip neigh show to 192.168.1.11
      ip neigh show to 192.168.1.12
      

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

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

      echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
      echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
      echo 1 > /proc/sys/net/ipv4/conf/eth2/arp_filter
      
      ip route add 192.168.1.0/24 dev eth0 table 100
      ip route add 192.168.1.0/24 dev eth1 table 101
      ip route add 192.168.1.0/24 dev eth2 table 102
      
      ip rule add from 192.168.1.10 lookup 100
      ip rule add from 192.168.1.11 lookup 101
      ip rule add from 192.168.1.12 lookup 102
      
    • очистить кэши ARP одноранговых узлов (при этом запросы DAD дублируются как GARP), чтобы при необходимости ускорить восстановление. Не требуется во время загрузки, так как таких кешей не было. Используйте arping iputils, а не автономный инструмент arping (RHEL: iputils, Debian: iputils-arping, не arping package), потому что синтаксис отличается.

      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

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

    ip route add default via 192.168.1.1 dev eth0 table 100
    ip route add default via 192.168.1.1 dev eth1 table 101
    ip route add default via 192.168.1.1 dev eth2 table 102
    

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