Сервер не отвечает на эхо-запрос -ICMP получен, но ничего не происходит

У вас есть несколько -домашних серверов, которые всегда усложняют маршрутизацию.

Ваша сеть может быть маршрутизирована таким образом. Это может быть более или менее сложно, но, вероятно, что-то вроде этого:

                  ┏━━━━━━┓
                  ┃laptop┃
                  ┗━━━━━━┛
               192.168.1.30/24
                      ┊
                    lan1
                      ┊
               192.168.1.1/24
                 ┌─────────┐
                 │ clients │
                 │ router  │
                 └─────────┘
                   x.x.x.x
                      ┊ 
                   y.y.y.y 
                 ┌─────────┐
  192.168.201.1/24 servers 192.168.203.1/24
   ╭┄┄┄┄┄┄┄┄┄┄┄┄┄│ router  │┄┄┄┄┄┄┄┄┄┄┄┄┄╮
   ┆             └─────────┘             ┆
   ┆                                     ┆
 lan201                               lan203
   ┆                                     ┆
   ┆             ┏━━━━━━━━━┓             ┆
   ╰┄┄┄┄┄┄┄┄┄┄┄┄┄┃         ┃┄┄┄┄┄┄┄┄┄┄┄┄┄╯
192.168.201.232/24  server 192.168.203.3/24
                 ┃         ┃
                 ┗━━━━━━━━━┛

Почему пакет игнорируется?

Ваши проблемы, скорее всего, связаны с тем, что на сервере включена часть функции защиты от -спуфинга, которая называется Strict Reverse Path Forwarding . В нескольких словах,входящий пакет разрешен на интерфейсе только в том случае, если тот же интерфейс будет использоваться для обратного направления его ответа.

Когда оба интерфейса настроены и маршрут по умолчанию использует 192.168.201.1, и вы пингуете 192.168.201.232 с ноутбука, пакеты приходят на сервер с «левым путем» и возвращаются с сервера также с «левым дорожка". На сервере можно спросить ядро, каковы будут его решения по маршрутизации :

путь к ноутбуку:

# ip route get from 192.168.201.232 192.168.1.30
192.168.1.30 from 192.168.201.232 via 192.168.201.1 dev enp10s0 uid 0 
    cache 

использует enp10s0 .

Мы сообщаем, что входящий пакет поступает с того же интерфейса(enp10s0 ), потому что мы знаем, что это будет делать предыдущий маршрутизатор:

# ip route get from 192.168.1.30 iif enp10s0 192.168.201.232
local 192.168.201.232 from 192.168.1.30 dev lo table local 
    cache <local> iif enp10s0 

поскольку это та же сторона, что и у исходящего пакета, этот входящий пакет принимается (и направляется в локальную систему ).

Если сейчас вы пропингуете 192.168.203.3, пакеты будут маршрутизироваться и приходить по «правильному пути», а конфигурация маршрута сервера подскажет, что нужно оставить сервер с «левым путем». Это асимметричный маршрут, и предыдущий SRPF не может проверить :различные интерфейсы.

Вы можете снова спросить ядро ​​о его решениях для этого случая. В то время как ответ, если бы он существовал, был бы направлен следующим образом:

# ip route get from 192.168.203.3 192.168.1.30
192.168.1.30 from 192.168.203.3 via 192.168.201.1 dev enp10s0 uid 0 
    cache 

с маршрутом по умолчанию и, таким образом, enp10s0

входящий пакет:

# ip route get from 192.168.1.30 iif enp11s0 192.168.203.3
RTNETLINK answers: Invalid cross-device link

отклоняется SRPF, поскольку входящий интерфейс enp11s0 не соответствует исходящему интерфейсу enp10s0 , который будет использоваться для связи с этим IP-адресом.

Если вы измените маршрут по умолчанию, отключив «левый путь» и унаследовав маршрут по умолчанию от DHCP на «правом пути», все сместится на enp11s0 и снова заработает.

Как заставить это работать?

• Что вряд ли сильно поможет

  Вы можете указать системе отключить проверку или ослабить ее Свободная переадресация по обратному пути . Когда задействован маршрут по умолчанию (есть )оба эффекта похожи (т.е. :не остается большого эффекта ), но в Linux проще его ослабить (набор 2 ), чем отключить его (установить 0 ), когда он включен в другом месте, потому что максимальное значение в конфигурации выигрывает . Вероятно, он был включен при загрузке системы в/etc/sysctl.d(YMMV )и мог быть отредактирован там. Так:

  sysctl -w net.ipv4.conf.enp11s0.rp_filter=2
  

  И предыдущий запрос больше не будет терпеть неудачу:

  # ip route get from 192.168.1.30 iif enp11s0 192.168.203.3
  local 192.168.203.3 from 192.168.1.30 dev lo table local 
      cache <local> iif enp11s0 
  

  Теперь два tcpdump, по одному на каждом интерфейсе, на сервере должны видеть входящие пакеты на enp11s0 и исходящие ответы на enp10s0 .

  Если ноутбук получил ответ, значит, вы закончили и можете на этом остановиться.

  Вероятно, не будет. Потому что на пути следующий элемент сети, маршрутизатор сервера, вероятно, также реализует Strict Reverse Path Forwarding. Или он может выступать в качестве брандмауэра и может счесть подозрительным пакет 192.168.203.3, поступающий с интерфейса, где только пакеты в 192.168.201.0/24 должны разрешать (защиту от -спуфинга, на что в любом случае нацелен SRPF ). Таким образом, пакет, вероятно, будет отброшен на один шаг позже.

• Что будет работать

  Всякий раз, когда задействовано множественное -подключение, маршрутизация -на основе политики должна использоваться. Это позволяет выбирать маршрут не только с адресом назначения в качестве селектора для решения, но и с различными другими критериями, наиболее распространенным из которых является исходный адрес. Здесь также необходим исходный адрес. В Linux это делается с помощью дополнительных таблиц маршрутизации (, которые, как обычно, используют пункт назначения в качестве селектора ).и наличие правил (, которые здесь будут использовать источник в качестве селектора ), выбирающего подходящую таблицу маршрутизации. Поскольку настройка зависит от исходного адреса, ее сложно интегрировать в динамическую среду, такую ​​как DHCP. Хотя вполне возможно, что :демоны, такие как dhclient или NetworkManager , имеют собственный набор ловушек для подключения сценариев, вы сэкономите время, используя конфигурации статических IP-адресов и объявив их. адреса, зарезервированные на DHCP-серверах.

  Маршруты из основной таблицы должны быть частично продублированы в дополнительные таблицы. Если сервер также является маршрутизатором (, например, :с LXC, Docker, виртуальными машинами... )необходимо обдумать дополнительные маршруты и, возможно, скопировать их в дополнительные таблицы маршрутизации. Конечно, если эти маршруты являются динамическими (, появляющимися при запуске контейнера ), настройка становится еще более сложной. Как обычно, здесь очень помогает ip route get.

  Итак. Создайте таблицу маршрутизации для каждой стороны (Я буду использовать не -, а -произвольные значения 201 и 203 для этих таблиц )и скопирую только то, что необходимо и относится к этой стороне. Добавьте к каждому из них маршрут по умолчанию. Хорошо, может использоваться только один маршрут по умолчанию... но для каждой таблицы маршрутизации. Здесь добавления только маршрутов по умолчанию достаточно, чтобы решить проблемы с маршрутизацией (, и на самом деле нужна только таблица маршрутизации 203 ). Если макет изменится (, например, :маршрутизация контейнеров... ), маршруты, ранее считавшиеся ненужными, следует снова обдумать. Кроме того, даже если он не всегда используется, все равно должен оставаться маршрут по умолчанию в основной таблице маршрутизации :, это будет маршрут по умолчанию «по умолчанию». Когда сервер действует как клиент и не определяет исходный IP-адрес при подключении, маршрут по умолчанию повлияет на автоматический выбор.

  ip route add table 201 default via 192.168.201.1
  ip route add table 203 default via 192.168.203.1
  

  Выберите их с помощью исходных -правил на основе:

  ip rule add from 192.168.201.232 lookup 201
  ip rule add from 192.168.203.3 lookup 203
  

  Результат:

  # ip route get from 192.168.203.3 192.168.1.30
  192.168.1.30 from 192.168.203.3 via 192.168.203.1 dev enp11s0 table 203 uid 0 
      cache 
  

  исходящий интерфейс переключился на enp11s0 с помощью таблицы маршрутизации 203.

  # ip route get from 192.168.1.30 iif enp11s0 192.168.203.3
  local 192.168.203.3 from 192.168.1.30 dev lo table local 
      cache <local> iif enp11s0 
  

  входящий пакет на том же интерфейсе больше не вызывает сбоев SRPF :тот же интерфейс.

  Следующий маршрутизатор также больше не будет путаться. Пинги ноутбука будут работать для обоих адресов.

  На сервере клиентские приложения, способные выбирать исходный адрес, будут косвенно изменять маршрут, выбранный их трафиком (, например :curl --interface 192.168.203.3 192.168.1.30, ping -I 192.168.203.3 192.168.1.30, но поскольку это специальный инструмент, вероятно, не ping -I enp11s0 192.168.1.30и т. д. ), и это просто сработает.