VPN-ul din Windows afișează 255.255.255.255: masca este greșită?

Tunelul se conectează, deschideți detaliile adaptorului și masca arată 255.255.255.255. Comparativ cu 255.255.255.0 din LAN-ul biroului pare stricată, și de obicei acolo începe greșeala. Pe o legătură punct-la-punct, o mască de gazdă este descrierea corectă a capătului local, iar rețelele îndepărtate sosesc ca rute, nu ca o subrețea atașată. Procedura de mai jos separă cele două întrebări, ca să nu reconstruiți un domeniu DHCP funcțional doar pentru a repara o valoare afișată.

O legătură punct-la-punct nu este un segment Ethernet

O interfață Ethernet are nevoie de o mască de subrețea pentru că fiecare adresă din acel interval este potențial accesibilă pe același cablu. Un tunel în stil PPP are exact un partener la celălalt capăt. Nu există domeniu de difuzare, nu există ARP și niciun motiv ca adresa locală să descrie un interval.

Negocierea adreselor pentru acel model este definită în RFC 1332, care descrie cum cele două capete cad de acord asupra adreselor. Ce nu face este să ofere clientului LAN-ul biroului ca rețea conectată direct. Clientul află unde este biroul instalând rute prin legătură, iar acele rute decid de fapt accesibilitatea.

Asta nu înseamnă că fiecare mască pe care o vedeți este corectă. Un client configurat greșit poate produce și adresare ciudată. Ideea este mai îngustă: o mască de gazdă pe acest tip de adaptor este de așteptat, deci singură nu este dovadă a unei defecțiuni.

Pasul 1: confirmați modelul interfeței

Uitați-vă ce este adaptorul înainte de a judeca ce spune. Șirul de descriere identifică driverul, iar lungimea prefixului adresei atribuite confirmă ce a negociat clientul:

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

A treia comandă este cea care încheie majoritatea disputelor. O unitate maximă de transmisie mică este caracteristică unei legături încapsulate, în timp ce o valoare asemănătoare Ethernet sugerează un alt model de adaptor virtual. Dacă descrierea numește un driver PPP sau RAS și prefixul este 32, vedeți exact proiectarea descrisă mai sus și puteți înceta să vă îngrijorați de mască.

Pasul 2: citiți ruta pentru destinația care eșuează

Accesibilitatea se decide pe destinație, iar o singură interfață conectată nu vă spune nimic despre asta. Întrebați direct tabela de rutare despre adresa la care utilizatorul încearcă de fapt să ajungă:

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

Find-NetRoute este răspunsul direct: numește interfața și adresa sursă pe care sistemul le-ar folosi pentru acea destinație. Dacă returnează tunelul, traficul către acea gazdă trece prin tunel, iar masca nu a fost niciodată problema.

Dacă returnează adaptorul fizic, comparați cele două rute candidate și metricile lor. O rută locală mai specifică, o intrare rămasă de la alt client sau o metrică mai mică pe calea fizică înving toate o rută largă de tunel. Rezultatul vizibil este o resursă inaccesibilă în timp ce tot restul funcționează. Prefixele mai lungi câștigă întotdeauna, așa că învingătorul este adesea o rută de gazdă pe care cineva a adăugat-o acum câteva luni și a uitat-o.

Verificați aici și ambele direcții. O rută către partea serverului este necesară, dar nu suficientă, pentru că și răspunsul trebuie să revină prin tunel. Când o gazdă internă funcționează și alta nu, diferența este de obicei în acest tabel, nu în configurația adaptorului.

Pasul 3: separați rezolvarea numelor de accesul la serviciu

O aplicație care nu deschide o partajare poate eșua într-una din două etape foarte diferite. Rezolvați numele, apoi atingeți adresa. Dacă prima eșuează și a doua funcționează, tunelul este în regulă, iar resolverul nu:

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

Un test de adresă reușit împreună cu un test de nume eșuat localizează problema în rezolvare, iar a doua comandă arată dacă interfața tunelului a primit măcar un server. Mulți clienți împing DNS-ul ca parte a configurației tunelului, iar un profil care ignoră acele opțiuni împinse va lăsa mașina să folosească un resolver care nu vede zona privată.

Nu tratați o adresă funcțională ca soluție permanentă. Conectarea prin adresă ocolește rezolvarea numelor și poate slăbi verificarea identității serverului pe care aplicația ar face-o altfel. Aceasta este o regresie de securitate deghizată în soluție temporară. Folosiți-o pentru a localiza defectul, apoi reparați rezolvarea.

Revenire: nu reconstruiți DHCP pentru o valoare afișată

Dacă ați început deja să modificați serviciul de adresare, opriți-vă și verificați dacă ceva din ce ați schimbat este esențial. Recrearea unui domeniu, reemiterea bailurilor sau mutarea grupului schimbă o stare de care depind alți clienți, și nimic din toate acestea nu este justificat de o mască de gazdă pe un adaptor punct-la-punct.

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

Rulați aceste trei după orice modificare țintită și comparați cu rularea anterioară. Rezultatul util este o cale documentată către resursă, nu un adaptor a cărui mască seamănă cu LAN-ul biroului.

Apoi notați ce a însemnat de fapt masca, pentru că următoarea persoană va deschide același dialog și va ajunge la aceeași concluzie greșită. O propoziție în notele profilului, că tunelul este punct-la-punct și subrețelele îndepărtate sosesc ca rute, economisește întreaga investigație data viitoare.