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

Изпълнете тези три след всяка целенасочена промяна и сравнете с предишното изпълнение. Полезният резултат е документиран път до ресурса, а не адаптер, чиято маска прилича на офисната локална мрежа.

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