VPN в Windows показывает 255.255.255.255: маска неверна?

Туннель подключается, вы открываете сведения об адаптере, и маска показывает 255.255.255.255. По сравнению с 255.255.255.0 офисной локальной сети это выглядит поломкой, и обычно именно здесь начинается ошибка. В соединении «точка-точка» маска хоста — правильное описание локального конца, а удалённые сети приходят как маршруты, а не как подключённая подсеть. Приведённая ниже процедура разделяет два вопроса, чтобы вы не перестраивали рабочую область DHCP только ради исправления отображаемого значения.

Соединение «точка-точка» — не сегмент Ethernet

Интерфейсу Ethernet нужна маска подсети, потому что каждый адрес в этом диапазоне потенциально достижим по тому же кабелю. Туннель в стиле PPP имеет ровно одного партнёра на другом конце. Здесь нет широковещательного домена, нет ARP и нет причины, по которой локальный адрес должен описывать диапазон.

Согласование адресов для такой модели определено в RFC 1332, где описано, как два конца договариваются о своих адресах. Чего он не делает — не передаёт клиенту офисную локальную сеть как непосредственно подключённую. Клиент узнаёт, где находится офис, устанавливая маршруты через соединение, и именно эти маршруты фактически определяют доступность.

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

Шаг 1: подтвердите модель интерфейса

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

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

Третья команда — та, что решает большинство споров. Низкий максимальный размер передаваемого блока характерен для инкапсулированного соединения, а значение, похожее на Ethernet, указывает на другую модель виртуального адаптера. Если в описании указан драйвер PPP или RAS и префикс равен 32, вы видите ровно ту схему, что описана выше, и можете перестать беспокоиться о маске.

Шаг 2: прочитайте маршрут для проблемного назначения

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

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute — прямой ответ: она указывает интерфейс и адрес источника, который система использовала бы для этого назначения. Если она возвращает туннель, трафик к этому хосту идёт через туннель, и маска никогда не была проблемой.

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

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

Шаг 3: отделите разрешение имён от доступа к службе

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

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

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

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

Откат: не перестраивайте DHCP из-за отображаемого значения

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

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

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

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