Почему Linux может отбросить правильный входящий пакет?
Linux проверяет не только адрес назначения, но при включённом rp_filter может сверить путь обратно к источнику. В strict mode пакет отклоняется, если интерфейс, на котором он пришёл, не является лучшим обратным маршрутом по FIB. Поэтому firewall может выглядеть открытым, а приложение не увидит запрос.
Частая причина — две сетевые карты, несколько провайдеров, policy routing или туннель. Запрос приходит по одному пути, а main table предлагает ответить через другой. Это не всегда ошибка маршрутизации как таковой, но строгая reverse-path validation воспринимает такую асимметрию как подозрительный источник.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.
Что называют асимметричной маршрутизацией?
Маршрут асимметричен, когда прямой и обратный трафик одной связи проходят через разные интерфейсы или шлюзы. Например, запрос приходит через uplink A, а правило по источнику отправляет ответ через uplink B. Сеть способна работать так намеренно, но stateful-компоненты должны понимать обе стороны потока.
Асимметрия встречается в multi-WAN, policy routing, прозрачном проксировании и при сочетании обычного маршрута с VPN. Наличие разных путей само по себе не доказывает поломку. Проблема возникает, когда проверка источника, NAT или conntrack ожидают симметрию, которой в реальной схеме нет.
Как работают значения rp_filter 0, 1 и 2?
Документация ядра определяет 0 как отсутствие source validation, 1 как strict mode и 2 как loose mode. В strict mode интерфейс входа должен совпасть с лучшим обратным путём. В loose mode достаточно, чтобы источник был достижим хотя бы через один интерфейс.
Для сложной или асимметричной маршрутизации документация ядра рекомендует loose mode, но это не универсальная команда для всех серверов. Учитывается максимальное значение между conf/all/rp_filter и настройкой конкретного интерфейса. Проверка только одного sysctl способна дать ложный вывод.
Почему fwmark и src_valid_mark меняют результат?
Policy routing часто выбирает таблицу по fwmark. По умолчанию reverse-path lookup для rp_filter может не учитывать mark так же, как основной маршрут пакета. Тогда рабочее правило отправки и проверка источника смотрят на разные таблицы и приходят к разным решениям.
Параметр src_valid_mark определяет, включать ли fwmark в reverse-path lookup. Его значение влияет и на выбор адреса для некоторых ICMP-ответов. Менять этот параметр отдельно от схемы маркировки нельзя: сначала фиксируют, где ставится mark, какие ip rules его читают и одинаково ли это работает в обоих направлениях.
Как провести read-only диагностику без изменения сети?
Снимите вывод ip rule show, ip route show table all и значений rp_filter для all и входящего интерфейса. Затем с помощью ip route get проверьте обратный путь к тестовому источнику с нужным source address и mark, если он используется. Эти команды читают состояние и не меняют маршруты.
Сопоставьте interface входа с результатом reverse lookup и приоритетами rules. Счётчики firewall и журналы martian source могут подтвердить, на каком этапе исчезает пакет. Не публикуйте полный сетевой вывод: в нём могут быть внутренние адреса, имена интерфейсов и детали инфраструктуры.
Как исправить обратный путь без полного отключения защиты?
Предпочтительное исправление — сделать policy routing последовательным: добавить корректную таблицу для нужного source, выстроить priorities и обеспечить обратный маршрут через ожидаемый интерфейс. Если асимметрия является частью дизайна, loose mode применяют точечно после оценки модели угроз и требований дистрибутива.
Не стоит начинать с глобального rp_filter=0. Это скрывает симптом и убирает source validation шире необходимого. Так же опасно добавлять случайные default routes: они могут переключить SSH, мониторинг или другой трафик. Изменение проектируют для одного интерфейса и одной тестовой сети, затем расширяют.
Как проверить исправление и выполнить откат?
После изменения повторяют те же ip route get и ip rule show, затем проверяют соединение с обеих сторон и подтверждают ожидаемый исходящий интерфейс. Отдельно тестируют трафик хоста и транзитный трафик: они могут проходить через разные rule и таблицы.
Для отката заранее сохраняют исходные rules, routes и sysctl из файлов конфигурации. Возврат выполняют в обратном порядке, сохраняя административный канал. Если результат нельзя объяснить одной таблицей и одним приоритетом, изменение лучше остановить и построить полную карту маршрутов.
Какие короткие ответы важно запомнить?
Может ли firewall показывать разрешение, а rp_filter всё равно отбросить пакет?
Да. Reverse-path validation выполняется на сетевом пути ядра и может отклонить пакет независимо от ожидаемого правила прикладного firewall. Поэтому проверяют оба механизма.
Нужно ли всегда ставить rp_filter в 0 для multi-WAN?
Нет. Документация ядра предусматривает loose mode для сложной маршрутизации, а корректные policy rules часто позволяют сохранить source validation. Решение зависит от конкретной схемы.
Почему проверяют и all, и конкретный интерфейс?
Ядро использует максимальное значение из conf/all/rp_filter и настройки интерфейса. Если посмотреть только один параметр, фактический режим проверки можно определить неверно.
Telegram-flow
Хотите подключить VPN без ручных настроек?
Откройте бота: он покажет trial или тариф, отправит файл подключения и QR-код прямо в Telegram.