VPN-клиентам RRAS нужен собственный пул IPv4 и обратный путь

VPN-клиент подключается и получает адрес, но нужный ему хост в LAN по-прежнему не может ответить. В Windows Routing and Remote Access внутренний адрес VPN-клиентов берётся из пула, который настраивается отдельно от LAN-адаптера сервера, и стороне LAN нужен маршрут обратно к этому пулу. Два изменения, а не одно, и отказывают они по-разному. Пройдите их по порядку, чтобы план адресов и обратный путь были доказаны до вывода старых диапазонов.

Зарезервируйте диапазон до открытия консоли

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

План адресов, живущий только в консоли, находится в одной перестройке от коллизии. Он также склонен расти: кто-то позже добавляет второй диапазон, и никто не проверяет первый. Держите план рядом с документацией сервера, а не в ветке чата.

LAN-адаптер сервера не определяет этот пул. Изменение публичного прослушивателя или добавление адаптера в LAN делает совсем другое. Поэтому клиенты могут подключаться и всё равно получать адрес не оттуда. Пул живёт в свойствах IPv4 сервера, а не в списке адаптеров.

Смена метода — это не добавление диапазона

В RRAS есть метод назначения и набор диапазонов. Переход с DHCP на статический пул — это смена метода. Добавление ещё одного блока, когда статический пул уже активен, — это смена диапазона.

Просмотрите обе операции, прежде чем запускать любую, и прочитайте, какая соответствует текущему состоянию сервера:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Второй cmdlet завершается ошибкой или создаёт непригодный пул, если сервер всё ещё на назначении DHCP. Первый заменяет метод, а не расширяет существующий пул. Ни один просмотр ничего не применяет, поэтому запустите подходящий, а затем подтвердите полученный пул в консоли. Если вы не уверены, в каком состоянии сервер, прочитайте метод назначения на странице свойств IPv4 и перечислите настроенные диапазоны:

Get-VpnIPAddressRange

Метод DHCP с пустым списком диапазонов означает, что применяется первый просмотр. Статический пул адресов с существующим диапазоном означает, что применяется второй.

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

LAN нужен обратный маршрут

Предположим, LAN — это 10.60.0.0/24, а сервер RRAS — 10.60.0.10 в ней. Хосту в этой LAN, отвечающему клиенту в 10.250.50.0/24, нужен путь к пулу через сервер RRAS. Без этого пути запрос приходит, а ответ умирает.

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

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

Докажите новый пул на одном устройстве, прежде чем выводить старый

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

Разрешение имён заслуживает отдельной проверки: доступ по IP может работать, пока DNS клиента всё ещё указывает на резолвер, до которого он не дотягивается. DNS-сервер в LAN доступен только если у клиента есть к нему маршрут и сервер принимает запросы из нового диапазона. Оба — частые упущения при переносе пула.

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

Проверьте результат тремя наблюдениями

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

С клиента подтвердите адрес и маршрут до одного хоста в LAN:

ipconfig | findstr /i "IPv4"
route print -4

С хоста в LAN подтвердите обратный путь и политику за один проход. Если ping не проходит, но приложение работает, недостающий кусок — скорее всего правило ICMP, а не маршрут. Если не проходит и то и другое, прочитайте маршрут на хосте, прежде чем править VPN. Запишите три результата в заявку на изменение, чтобы следующий человек начал с доказательств.