Windows-VPN viser 255.255.255.255: er masken forkert?

Tunnelen opretter forbindelse, du åbner adapteroplysningerne, og masken viser 255.255.255.255. Sammenlignet med 255.255.255.0 fra kontor-LAN'et ser det forkert ud, og det er normalt der, fejlen begynder. På en punkt-til-punkt-forbindelse er en værtsmaske den korrekte beskrivelse af det lokale endepunkt, og de eksterne netværk kommer ind som ruter i stedet for som et tilsluttet subnet. Fremgangsmåden nedenfor adskiller de to spørgsmål, så du ikke genopbygger et fungerende DHCP-område for at rette en vist værdi.

En punkt-til-punkt-forbindelse er ikke et Ethernet-segment

Et Ethernet-interface har brug for en subnetmaske, fordi hver adresse i det interval potentielt kan nås på samme kabel. En tunnel i PPP-stil har præcis én peer i den anden ende. Der er intet broadcastdomæne, ingen ARP og ingen grund til, at den lokale adresse skulle beskrive et interval.

Adresseforhandlingen for den model er defineret i RFC 1332, som beskriver, hvordan de to ender bliver enige om deres adresser. Det, den ikke gør, er at give klienten kontor-LAN'et som et direkte tilsluttet netværk. Klienten lærer, hvor kontoret er, ved at installere ruter gennem forbindelsen, og det er disse ruter, der reelt afgør tilgængeligheden.

Det betyder ikke, at enhver maske, du ser, er korrekt. En fejlkonfigureret klient kan også give mærkelig adressering. Pointen er snævrere: en værtsmaske på denne type adapter er forventet, så den er ikke i sig selv bevis på en fejl.

Trin 1: bekræft interfacemodellen

Se, hvad adapteren er, før du vurderer, hvad den siger. Beskrivelsesstrengen identificerer driveren, og præfikslængden på den tildelte adresse bekræfter, hvad 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 kommando er den, der afgør de fleste diskussioner. En lav maksimal transmissionenhed er typisk for en indkapslet forbindelse, mens en Ethernet-lignende værdi peger på en anden virtuel adaptermodel. Hvis beskrivelsen nævner en PPP- eller RAS-driver, og præfikset er 32, ser du præcis det design, der er beskrevet ovenfor, og kan holde op med at bekymre dig om masken.

Trin 2: læs ruten for den destination, der fejler

Tilgængelighed afgøres pr. destination, og et enkelt tilsluttet interface siger intet om det. Spørg rutetabellen direkte om den adresse, brugeren faktisk prøver at 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 svar: den angiver det interface og den kildeadresse, systemet ville bruge til den destination. Hvis den returnerer tunnelen, går trafikken til den vært gennem tunnelen, og masken var aldrig problemet.

Hvis den returnerer den fysiske adapter, skal du sammenligne de to kandidatruter og deres metrikker. En mere specifik lokal rute, en rest fra en anden klient eller en lavere metrik på den fysiske vej vinder alle over en bred tunnelrute. Det synlige resultat er en ressource, der ikke kan nås, mens alt andet virker. Længere præfikser vinder altid, så vinderen er ofte en værtsrute, som nogen tilføjede for måneder siden og glemte.

Kontroller også begge retninger, mens du er her. En rute til serversiden er nødvendig, men ikke tilstrækkelig, fordi svaret også skal tilbage gennem tunnelen. Når en intern vært virker og en anden ikke, ligger forskellen normalt i denne tabel og ikke i adapterkonfigurationen.

Trin 3: adskil navneopslag fra tjenesteadgang

Et program, der ikke kan åbne en delt mappe, kan fejle på et af to meget forskellige trin. Slå navnet op, og nå derefter adressen. Hvis det første fejler, og det andet virker, er tunnelen fin, og resolveren er ikke:

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

En vellykket adressetest plus en mislykket navnetest lokaliserer problemet til opløsningen, og den anden kommando viser, om tunnelinterfacet overhovedet har fået en server. Mange klienter skubber DNS som en del af tunnelkonfigurationen, og en profil, der ignorerer disse skubbede valgmuligheder, efterlader maskinen med en resolver, der ikke kan se den private zone.

Behandl ikke en fungerende adresse som den permanente løsning. At forbinde via adresse omgår navneopløsning og kan underminere den serveridentitetskontrol, programmet ellers ville udføre. Det er en sikkerhedsregression forklædt som en midlertidig løsning. Brug den til at lokalisere fejlen, og reparer derefter opløsningen.

Rul tilbage: genopbyg ikke DHCP på grund af en vist værdi

Hvis du allerede er begyndt at ændre adressetjenesten, så stop og kontroller, om noget af det, du ændrede, er bærende. At genskabe et område, genudstede leases eller flytte puljen ændrer tilstand, som andre klienter afhænger af, og intet af det er berettiget af en værtsmaske 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

Kør disse tre efter enhver målrettet ændring, og sammenlign med kørslen før. Det nyttige resultat er en dokumenteret vej til ressourcen, ikke en adapter, hvis maske ligner kontor-LAN'et.

Skriv derefter ned, hvad masken faktisk betød, for den næste person åbner den samme dialog og når den samme forkerte konklusion. Én sætning i profilnoterne om, at tunnelen er punkt-til-punkt, og at de eksterne subnet ankommer som ruter, sparer hele undersøgelsen næste gang.