Windows-VPN viser 255.255.255.255: er masken feil?
På en punkt-til-punkt-tunnel er en vertsmaske normal. Bekreft grensesnittmodellen, les ruten for verten som feiler, og skill DNS fra tjenestetilgang.
Tunnelen kobles til, du åpner adapterdetaljene, og masken viser 255.255.255.255. Sammenlignet med 255.255.255.0 på kontor-LAN-et ser det ødelagt ut, og det er vanligvis der feilen begynner. På en punkt-til-punkt-forbindelse er en vertsmaske den riktige beskrivelsen av det lokale endepunktet, og fjernnettene kommer inn som ruter i stedet for som et tilkoblet subnett. Fremgangsmåten nedenfor skiller de to spørsmålene, slik at du ikke bygger opp et fungerende DHCP-område på nytt for å rette en vist verdi.
En punkt-til-punkt-forbindelse er ikke et Ethernet-segment
Et Ethernet-grensesnitt trenger en subnettmaske fordi hver adresse i det området potensielt er nåbar på samme kabel. En tunnel i PPP-stil har nøyaktig én peer i andre enden. Det finnes ingen kringkastingsdomene, ingen ARP og ingen grunn til at den lokale adressen skal beskrive et område.
Adresseforhandlingen for den modellen er definert i RFC 1332, som beskriver hvordan de to endene blir enige om adressene sine. Det den ikke gjør, er å gi klienten kontor-LAN-et som et direkte tilkoblet nett. Klienten lærer hvor kontoret er ved å installere ruter gjennom forbindelsen, og det er disse rutene som faktisk avgjør nåbarheten.
Det betyr ikke at enhver maske du ser er riktig. En feilkonfigurert klient kan også gi merkelig adressering. Poenget er snevrere: en vertsmaske på denne typen adapter er forventet, så den er ikke i seg selv bevis på en feil.
Trinn 1: bekreft grensesnittmodellen
Se hva adapteren er før du vurderer hva den sier. Beskrivelsesstrengen identifiserer driveren, og prefikslengden på den tildelte adressen bekrefter hva klienten har forhandlet:
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 avgjør de fleste diskusjoner. En lav maksimal overføringsenhet er typisk for en innkapslet forbindelse, mens en Ethernet-lignende verdi tyder på en annen virtuell adaptermodell. Hvis beskrivelsen nevner en PPP- eller RAS-driver og prefikset er 32, ser du nøyaktig designet som er beskrevet ovenfor, og kan slutte å bekymre deg for masken.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Trinn 2: les ruten for destinasjonen som feiler
Nåbarhet avgjøres per destinasjon, og ett enkelt tilkoblet grensesnitt sier ingenting om det. Spør rutetabellen direkte om adressen brukeren 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: den navngir grensesnittet og kildeadressen systemet ville brukt for den destinasjonen. Hvis den returnerer tunnelen, går trafikken til den verten gjennom tunnelen, og masken var aldri problemet.
Hvis den returnerer den fysiske adapteren, sammenlign de to kandidatrutene og måleverdiene deres. En mer spesifikk lokal rute, en rest fra en annen klient eller en lavere måleverdi på den fysiske veien vinner alle over en bred tunnelrute. Det synlige resultatet er en ressurs som ikke er nåbar mens alt annet fungerer. Lengre prefikser vinner alltid, så vinneren er ofte en vertsrute som noen la til for måneder siden og glemte.
Kontroller også begge retninger mens du er her. En rute til serversiden er nødvendig, men ikke tilstrekkelig, fordi svaret også må komme tilbake gjennom tunnelen. Når én intern vert fungerer og en annen ikke, ligger forskjellen vanligvis i denne tabellen og ikke i adapterkonfigurasjonen.
Trinn 3: skill navneoppslag fra tjenestetilgang
Et program som ikke åpner en delt mappe, kan feile på ett av to svært forskjellige trinn. Slå opp navnet, og nå deretter adressen. Hvis det første feiler og det andre fungerer, er tunnelen i orden og resolveryen ikke:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445
En vellykket adressetest pluss en mislykket navnetest lokaliserer problemet til oppslag, og den andre kommandoen viser om tunnelgrensesnittet i det hele tatt har fått en server. Mange klienter sender DNS som en del av tunnelkonfigurasjonen, og en profil som ignorerer disse sendte valgene, lar maskinen bruke en resolver som ikke ser den private sonen.
Ikke behandle en fungerende adresse som den permanente løsningen. Å koble til via adresse omgår navneoppslag og kan undergrave serveridentitetskontrollen som programmet ellers ville gjort. Det er en sikkerhetsregresjon forkledd som en midlertidig løsning. Bruk den til å lokalisere feilen, og reparer deretter oppslaget.
Tilbakerulling: ikke bygg DHCP på nytt for en vist verdi
Hvis du allerede har begynt å endre adressetjenesten, stopp og kontroller om noe av det du endret er bærende. Å gjenopprette et område, utstede nye leases eller flytte poolen endrer tilstand som andre klienter er avhengige av, og ingenting av det er berettiget av en vertsmaske på en 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
Kjør disse tre etter hver målrettede endring og sammenlign med kjøringen før. Det nyttige resultatet er en dokumentert vei til ressursen, ikke en adapter der masken ligner kontor-LAN-et.
Skriv deretter ned hva masken faktisk betydde, for den neste personen åpner samme dialog og trekker samme feilaktige slutning. Én setning i profilnotatene om at tunnelen er punkt-til-punkt og at fjernsubnettene kommer inn som ruter, sparer hele undersøkelsen neste gang.