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

Извршете ги овие три по секоја насочена промена и споредете со претходното извршување. Корисниот резултат е документирана патека до ресурсот, а не адаптер чија маска личи на канцелариската локална мрежа.

Потоа запишете што всушност значела маската, бидејќи следниот човек ќе го отвори истиот дијалог и ќе дојде до истиот погрешен заклучок. Една реченица во белешките на профилот, дека тунелот е точка-точка и оддалечените подмрежи пристигнуваат како рути, ја штеди целата истрага следниот пат.