Windows-VPN viser 255.255.255.255: er maska feil?

Tunnelen koplar seg til, du opnar adapterdetaljane, og maska viser 255.255.255.255. Samanlikna med 255.255.255.0 på kontor-LAN-et ser det øydelagt ut, og det er vanlegvis der feilen byrjar. På ein punkt-til-punkt-lenke er ei vertsmaske den rette skildringa av den lokale enden, og fjernnetta kjem inn som ruter i staden for som eit tilkopla subnett. Framgangsmåten nedanfor skil dei to spørsmåla, så du ikkje byggjer opp att eit fungerande DHCP-område berre for å rette ein vist verdi.

Ei punkt-til-punkt-lenke er ikkje eit Ethernet-segment

Eit Ethernet-grensesnitt treng ei subnettmaske fordi kvar adresse i det området potensielt er nåbar på same kabel. Ein tunnel i PPP-stil har nøyaktig ein partnar i andre enden. Det finst ikkje eit kringkastingsdomene, ingen ARP og ingen grunn til at den lokale adressa skal skildre eit område.

Adresseforhandlinga for den modellen er definert i RFC 1332, som skildrar korleis dei to endane blir samde om adressene sine. Det han ikkje gjer, er å gje klienten kontor-LAN-et som eit direkte tilkopla nett. Klienten lærer kvar kontoret er ved å installere ruter gjennom lenka, og det er desse rutene som faktisk avgjer nåbarheita.

Dette tyder ikkje at kvar maske du ser er rett. Ein feilkonfigurert klient kan òg gje merkeleg adressering. Poenget er trongare: ei vertsmaske på denne typen adapter er venta, så ho er ikkje i seg sjølv eit prov på feil.

Steg 1: stadfest grensesnittmodellen

Sjå kva adapteren er før du vurderer kva han seier. Skildringstrengen identifiserer drivaren, og prefikslengda på den tildelte adressa stadfestar kva klienten forhandla om:

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

Den tredje kommandoen er den som avgjer dei fleste diskusjonane. Ei låg maksimal overføringseining er typisk for ei innkapsla lenke, medan ein Ethernet-liknande verdi peikar på ein annan virtuell adaptermodell. Viss skildringa nemner ein PPP- eller RAS-drivar og prefikset er 32, ser du nøyaktig designet som er skildra ovanfor, og kan slutta å uroa deg for maska.

Steg 2: les ruta for destinasjonen som feilar

Nåbarheit blir avgjort per destinasjon, og eitt einskilt tilkopla grensesnitt seier ingenting om det. Spør rutetabellen direkte om adressa brukaren faktisk prøver å nå:

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

Find-NetRoute er det direkte svaret: han nemner grensesnittet og kjeldeadressa systemet ville bruke for den destinasjonen. Viss han returnerer tunnelen, går trafikken til den verten gjennom tunnelen, og maska var aldri problemet.

Viss han returnerer den fysiske adapteren, samanlikn dei to kandidatrutene og måleverdiane deira. Ei meir spesifikk lokal rute, ein rest frå ein annan klient eller ein lågare måleverdi på den fysiske vegen vinn alle over ei brei tunnelrute. Det synlege resultatet er ein ressurs som ikkje er nåbar medan alt anna fungerer. Lengre prefiks vinn alltid, så vinnaren er ofte ei vertsrute som nokon la til for månader sidan og gløymde.

Kontroller òg begge retningane medan du er her. Ei rute til serversida er naudsynt, men ikkje nok, fordi svaret òg må kome tilbake gjennom tunnelen. Når ein intern vert fungerer og ein annan ikkje, ligg skilnaden oftast i denne tabellen og ikkje i adapterkonfigurasjonen.

Steg 3: skil namneoppløysing frå tenestetilgang

Eit program som ikkje opnar ein delt mappe, kan feile på eitt av to svært ulike trinn. Løys opp namnet, og nå deretter adressa. Viss det første feilar og det andre fungerer, er tunnelen i orden og oppløysaren ikkje:

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

Ein vellukka adressetest pluss ein mislukka namnetest lokaliserer problemet til oppløysinga, og den andre kommandoen viser om tunnelgrensesnittet i det heile fekk ein tenar. Mange klientar dyttar DNS som ein del av tunnelkonfigurasjonen, og ein profil som ignorerer desse dytta vala, lèt maskinen bruke ein oppløysar som ikkje ser den private sona.

Ikkje handsam ei fungerande adresse som den permanente løysinga. Å kople til via adresse omgår namneoppløysing og kan svekkje tenaridentitetskontrollen som programmet elles ville gjort. Det er ein tryggleiksregresjon forkledd som ei mellombels løysing. Bruk han til å lokalisere feilen, og reparer deretter oppløysinga.

Tilbakerulling: bygg ikkje DHCP på nytt for ein vist verdi

Viss du alt har byrja å endre adressetenesta, stopp og kontroller om noko av det du endra er berande. Å opprette eit område på nytt, gje ut leiger på nytt eller flytte bassenget endrar tilstand som andre klientar er avhengige av, og ingenting av det er grunngjeve av ei vertsmaske på ein punkt-til-punkt-adapter.

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

Køyr desse tre etter kvar målretta endring og samanlikn med førre køyring. Det nyttige resultatet er ein dokumentert veg til ressursen, ikkje ein adapter der maska liknar kontor-LAN-et.

Skriv så ned kva maska faktisk tydde, for den neste personen opnar same dialogen og kjem til same feilaktige slutning. Éin setning i profilnotata om at tunnelen er punkt-til-punkt og at fjernsubnetta kjem inn som ruter, sparer heile granskinga neste gong.