Ответы Linux VPN пропадают? Проверьте rp_filter и маршрут

Запросы покидают машину, партнёр VPN отвечает, а ответ так и не доходит до сокета. Туннель поднят, журналы партнёра показывают отправку пакета, и ничто в приложении не объясняет тишину. В Linux один из обычных подозреваемых — фильтрация обратного пути: входящий пакет IPv4 может быть отброшен, когда проверка источника не совпадает с маршрутом, который ядро ожидает для этого источника. Последовательный разбор показывает, причина это или совпадение. Он также удерживает от отключения защиты, чтобы починить отсутствующий маршрут.

Что решает проверка источника

Ядро проверяет, правдоподобен ли адрес источника пакета для интерфейса, через который он пришёл, обращаясь к таблице маршрутизации за маршрутом обратно к этому источнику. Если обратный маршрут указывает в другое место, пакет может быть отброшен прежде, чем его увидит любое правило межсетевого экрана или сокет приложения. Эта проверка существует, чтобы усложнить некоторые схемы подмены, и поэтому асимметричные и маршрутизируемые по политике схемы натыкаются на неё, тогда как любой обычный клиент в той же сети работает нормально. У обычных клиентов симметричная маршрутизация, и именно это проверка и предполагает.

Важное слово — правдоподобен. Пакет может быть совершенно законным и всё равно не пройти проверку, потому что проверяется не законность.

Читайте фактический режим, а не одно поле

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Поиск маршрута в третьей строке — это то, что люди пропускают. Он говорит, что ядро думает об источнике, и это ровно вход проверки.

Найдите несоответствие до того, как менять проверку

Выясните, почему ответ приходит на этот интерфейс и должен ли его обратный маршрут отличаться. Правило политики, которое отправляет запросы одним путём, а ответы возвращает другим, — законная схема, и именно её отвергает строгая проверка. Метки, используемые в маршрутизации по политике, тоже могут иметь значение, потому что они меняют то, что возвращает обратный поиск.

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

Не отключайте проверки источника глобально как первую реакцию. Это меняет конкретную диагностику на широкое изменение поведения, которое потом придётся помнить.

Избирательная правка, которую можно защитить

Если узкая правка действительно необходима, ограничьте её интерфейсом, которому она нужна, запишите причину и поместите её в конфигурацию, которой принадлежит этот интерфейс, чтобы она пережила перезагрузку. Затем проверьте заново именно тот поток, который сломался, от того же источника к тому же назначению, а не ping до чего-то удобного.

Включите случай, который по-прежнему должен отклоняться. Если этот случай теперь проходит, правка ослабила больше, чем один путь, который вы хотели починить.

Держите IPv4 и IPv6 раздельно

Знакомый на вид sysctl не является политикой для каждого семейства адресов. У IPv6 своё поведение и свои настройки, и машина может быть строгой в одном семействе и снисходительной в другом, пока никто не заметит, пока не откажет конкретное назначение. Проверьте оба, если нагрузка использует оба.

Запишите режим, интерфейс, вывод поиска маршрута и причину изменения в одном месте. Следующий человек найдёт настройку и никаких объяснений и либо удалит её, либо скопирует туда, где ей не место.