VPN-шлюзу нужна пересылка IP: что проверить

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

Две роли независимы, как и два семейства адресов.

Ответ на собственный адрес ничего не доказывает

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

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

То же предложение относится к межсетевому экрану перед решением о пересылке, у которого своя политика о том, что можно пересылать.

Проверяйте каждое семейство адресов отдельно

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

Пересылка — одно из четырёх требований

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

Облачные платформы добавляют пятое соображение. Некоторые принудительно проверяют источник и назначение на инстансах, что отбрасывает пересылаемые пакеты независимо от того, как настроено ядро гостя. Авторитетом там служит собственная документация платформы по сетям, а не вывод sysctl внутри VM.

Проверяйте со стороны клиента, а не шлюза

Тест, запущенный в оболочке самого шлюза, не проходит ни по одному участку пути пересылки, который вы только что включили. Создайте трафик с клиента, у которого есть проблема, и подтвердите, что он достигает чего-то за шлюзом, а не самого шлюза. Это единственный тест, который задействует изменённую вами роль.

Держите правила прослушивания и правила пересылки отдельно в голове и в журнале изменений. Открытие порта VPN допускает клиентов к службе; оно ничего не даёт им в сети за ней, и в списке межсетевого экрана, который рос годами, эти две вещи выглядят одинаково.

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