Почему клиенты Access Server недоступны из локальной сети

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

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

Прочитайте адрес источника, который видит служба

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

Добавьте маршрут там, где решается ответ

Маршрут принадлежит шлюзу, который внутренняя служба уже использует, а не самой службе, если только она не маршрутизирует собственный трафик. Направьте его на достижимый частный адрес Access Server, который отличается от туннельного адреса клиента.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

Пересылка и фильтры должны согласовываться с маршрутом

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Фильтрация с учётом состояния объясняет симптом, который уводит людей не туда. Ответ внутри установленного потока не нуждается в новом входящем правиле, поэтому соединение, зависающее после SYN-ACK, блокируется не отсутствующим правилом accept; оно отбрасывается или маршрутизируется неверно. Сохраняйте это различие, потому что оно отделяет изменение маршрутизации от изменения межсетевого экрана.

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

Маршрутизация или маскарадинг: выберите осознанно

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

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

Подсеть за клиентом — отдельная задача

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

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

Проверьте одним потоком и одной записью

Докажите путь одним соединением вместо общего теста достижимости. Наблюдайте один и тот же поток с обеих сторон: запрос, приходящий в службу, и ответ, покидающий её.

tcpdump -ni any host 10.90.0.25 and port 443

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

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

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