VPN на роутере работает, но клиенты LAN остаются без интернета

Роутер выходит в интернет через свой туннель, а устройства за ним — нет. Пересылка, трансляция и обратные маршруты — это разные разрешения.

Состояние говорит, что туннель поднят, браузер на самом роутере загружает страницы, а каждое устройство за ним всё равно уходит в тайм-аут. Это сочетание сужает проблему до уровня, о котором большинство руководств по VPN никогда не упоминают: роутер — не единственный хост, чьи пакеты должны выжить в туннеле. Локально созданный трафик и пересылаемый трафик идут разными путями через одну и ту же коробку. Проверьте с клиента, и разница перестанет быть теоретической.

Читайте сбой с хоста LAN

Начните с устройства, которое не работает, потому что диагностика на роутере отвечает на другой вопрос. Убедитесь, что шлюз по умолчанию у клиента — этот роутер, запишите его адрес источника и подсеть, а затем посмотрите, что уходит из туннельного интерфейса роутера.

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

Локальный и пересылаемый трафик различаются

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

Обратный путь тоже должен существовать

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

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

DNS клиента относится к тому же обзору. Резолвер роутера может отвечать, а клиент, направленный на другой сервер, не получает вообще ничего.

Проверьте один разрешённый и один запрещённый поток

После исправления проверьте новое соединение с клиента, а не существующую сессию роутера. Затем убедитесь, что сегмент, который не должен использовать туннель, по-прежнему его не использует.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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

Похожие статьи