Маршрутизируемый клиент VPN достигает сервера, но не хостов LAN

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

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

Следите за ответом, а не за запросом

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

На клиенте симптом — тихий таймаут: ни отказа, ни сброса, просто ничего. Просмотр общей папки зависает, ping сообщает об отсутствии ответа, а журналы сервера выглядят здоровыми, потому что сервер сделал своё дело.

Поместите обратный маршрут туда, куда смотрят хосты

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Почему NAT источника выглядит как исправление

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Облачный путь требует трёх настроек

В VPC тот же пробел возвращается в другой форме, потому что у подсети вообще нет маршрута для диапазона клиентов. Таблице маршрутизации нужна запись для пула туннеля, указывающая на сетевой интерфейс инстанса, а на интерфейсе нужно отключить проверку источника и назначения, чтобы платформа принимала пакеты, источник которых не его собственный адрес. Группы безопасности и сетевые ACL также должны пропускать пул в обоих направлениях.

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

Выполните проверки в этом порядке

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

Завершите снимком, сделанным на хосте LAN, пока клиент его пингует. Запрос, который приходит без соответствующего ответа, доказывает обратный путь, а запрос, который никогда не приходит, возвращает вину серверу или туннелю.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Проверка источника и назначения описана в руководстве по эластичным сетевым интерфейсам. Настройте её на интерфейсе, который действительно несёт трафик туннеля, а не на постороннем адаптере, подключённом к тому же инстансу.

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