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

Запустіть ці три команди після будь-якої точкової зміни й порівняйте з попереднім запуском. Корисний результат — задокументований шлях до ресурсу, а не адаптер, чия маска схожа на офісну локальну мережу.

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