Пользователь шлюза в Access Server: маршрутизация LAN филиала клиента

Можно пинговать туннельный адрес клиента OpenVPN и всё равно не достичь ни одного узла в LAN за ним. Access Server выдаёт клиенту адрес из пула VPN, и адрес пула — это всё, что сервер считает своим. Префикс филиала — отдельный факт, который нужно объявить, и даже тогда филиалу нужен пересылающий узел, а головному офису — обратный путь. Маршрут, вписанный не туда, выглядит как решение и ничего не меняет.

Два адреса, два разных притязания

Когда клиент подключается, Access Server выдаёт ему адрес из настроенного пула VPN, например 10.90.0.0/24. Это выделение — аренда для одного узла. Ничто в соединении не говорит, что тот же клиент стоит и перед 10.60.0.0/24, и сервер не станет угадывать: префикс LAN доступен через конкретного клиента только тогда, когда администратор объявит его.

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

Что устанавливает настройка шлюза

В Admin Web UI объявление — свойство пользователя: включите Configure VPN gateway у пользователя-коннектора и введите реальный префикс филиала в Network on the VPN client side. Этот пользователь аутентифицируется как любой другой, поэтому ему нужна политика учётных данных для устройства без надзора, а его профиль автовхода — секрет.

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

Директива в стиле Community, вставленная в сгенерированный файл, в этой модели не участвует. Продукт владеет таблицей маршрутизации, которую отправляет; строка, изменённая вручную, перезаписывается или игнорируется.

Завершите обратные пути обеих сетей

Конкретный план: головной офис 10.40.0.0/24, филиал 10.60.0.0/24, пул VPN 10.90.0.0/24, а Access Server доступен по частному адресу со стороны головного офиса. Маршрутизатору головного офиса нужны маршруты для префикса филиала и для пула, оба в сторону Access Server. Без них туннель несёт запрос, а ответ уходит через шлюз по умолчанию, что даёт полуоткрытое соединение.

В филиале коннектор должен пересылать пакеты, не адресованные ему самому: пересылка IP в его операционной системе плюс разрешение, ограниченное интерфейсами туннеля и LAN; в Linux это net.ipv4.ip_forward=1 вместе с правилами цепочки forward, в Windows — routing and remote access. Затем узлам филиала нужен обратный путь: либо коннектор является их шлюзом по умолчанию, либо существующий шлюз несёт конкретные маршруты для префиксов головного офиса и пула.

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

Читайте сбой как путь

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

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

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

Руководство Access Server по соединению сайт-сайт перечисляет те же настройки в порядке продукта; стоит пройти его один раз.