Нет интернета в Windows VPN? Подозреваемый — пул адресов

Windows показывает туннель подключённым и помечает его Нет доступа к интернету, что люди воспринимают как особенность Windows. Это утверждение о том, что получил клиент: нет пригодного шлюза по умолчанию, нет работающего резолвера или нет обратного пути для адресов внутри туннеля. Когда сервер — это Windows Incoming Connection, одна настройка объясняет большинство таких сообщений. Метка не диагноз, но она сужает поиск до трёх мест.

Прочитайте аренду, прежде чем её менять

Запустите ipconfig /all на клиенте и найдите адаптер VPN среди записей. Указанные в нём адрес, шлюз по умолчанию и DNS-сервер — это нужные вам факты, и они часто отличаются от того, что администратор считает выданным.

Три шаблона соответствуют трём неисправностям. Адрес в 169.254.0.0/16 означает, что клиент не получил ничего и сам назначил себе link-local адрес. Правдоподобный адрес без шлюза означает, что пул был выдан без параметра, дающего клиенту маршрут по умолчанию. Полная аренда, которая всё равно никуда не попадает, указывает на пересылку или трансляцию на стороне сервера.

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

Почему автоматическое назначение может оставить без шлюза

Запись Incoming Connections имеет собственные свойства IPv4, отдельные от физического адаптера. Настройка по умолчанию там предлагает назначать адреса автоматически, что полагается на встроенный распределитель подключения для выдачи адреса, маски, шлюза и DNS.

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

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

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

Задайте явный диапазон, который сервер может маршрутизировать

Выберите небольшой блок внутри подсети, доступной серверу, вне диапазона, который раздаёт LAN-маршрутизатор, и вне любого другого пула в сети. Если сервер находится на 172.20.10.0/24, а маршрутизатор держит 172.20.10.1, короткий блок у верхнего края этой подсети, скажем с 172.20.10.201 по 172.20.10.209, держит аренды туннеля подальше от раздачи, которой маршрутизатор уже управляет.

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

Эти команды печатают получившуюся конфигурацию и маршруты, которые теперь есть у клиента:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

Адрес — это не путь в интернет

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

Internet Connection Sharing — короткий путь. Он превращает адаптер, смотрящий в интернет, в общий шлюз и ведёт собственную адресацию, что может переписать адрес этого адаптера и оставить существующее правило NAT указывающим на значение, которого больше нет. Запишите исходные настройки перед включением.

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

Сначала исключите внешний путь

Никакой пул не поможет, если туннель не формируется. Протокол решает, что должен нести путь: PPTP хочет TCP 1723 и GRE, а GRE — это IP-протокол 47, а не порт; L2TP/IPsec хочет UDP 1701 плюс 500 и 4500; SSTP хочет TCP 443.

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

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