Windows-VPN toont 255.255.255.255: is het masker fout?

De tunnel verbindt, u opent de adaptergegevens en het masker toont 255.255.255.255. Vergeleken met de 255.255.255.0 van het kantoor-LAN lijkt het kapot, en daar begint de fout meestal. Bij een punt-naar-punt-verbinding is een hostmasker de juiste beschrijving van het lokale eindpunt, en de externe netwerken komen binnen als routes in plaats van als een aangesloten subnet. De procedure hieronder scheidt de twee vragen, zodat u geen werkende DHCP-scope opnieuw opbouwt om een weergegeven waarde te corrigeren.

Een punt-naar-punt-verbinding is geen Ethernet-segment

Een Ethernet-interface heeft een subnetmasker nodig omdat elk adres in dat bereik mogelijk op dezelfde kabel bereikbaar is. Een PPP-achtige tunnel heeft precies één peer aan de andere kant. Er is geen broadcastdomein, geen ARP en geen reden waarom het lokale adres een bereik zou beschrijven.

De adresonderhandeling voor dat model is vastgelegd in RFC 1332, die beschrijft hoe beide uiteinden het over hun adressen eens worden. Wat die niet doet, is de client het kantoor-LAN als direct aangesloten netwerk geven. De client leert waar het kantoor is door routes via de verbinding te installeren, en die routes bepalen feitelijk de bereikbaarheid.

Dit betekent niet dat elk masker dat u ziet correct is. Een verkeerd geconfigureerde client kan ook vreemde adressering opleveren. Het punt is smaller: een hostmasker op dit soort adapter is te verwachten, dus het is op zichzelf geen bewijs van een storing.

Stap 1: bevestig het interfacemodel

Kijk wat de adapter is voordat u beoordeelt wat hij zegt. De beschrijvingsreeks identificeert het stuurprogramma, en de prefixlengte van het toegewezen adres bevestigt wat de client heeft onderhandeld:

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

Het derde commando beslecht de meeste discussies. Een lage maximale transmissie-eenheid is kenmerkend voor een ingekapselde verbinding, terwijl een Ethernet-achtige waarde op een ander virtueel adaptermodel wijst. Als de beschrijving een PPP- of RAS-stuurprogramma noemt en de prefix is 32, ziet u precies het hierboven beschreven ontwerp en kunt u ophouden zich zorgen te maken over het masker.

Stap 2: lees de route voor de bestemming die faalt

Bereikbaarheid wordt per bestemming bepaald, en één enkele verbonden interface zegt daar niets over. Vraag de routetabel rechtstreeks naar het adres dat de gebruiker echt probeert te bereiken:

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

Find-NetRoute is het directe antwoord: het noemt de interface en het bronadres dat het systeem voor die bestemming zou gebruiken. Als het de tunnel teruggeeft, gaat verkeer naar die host door de tunnel en was het masker nooit het probleem.

Als het de fysieke adapter teruggeeft, vergelijk dan de twee kandidaatroutes en hun metrieken. Een specifiekere lokale route, een restant van een andere client of een lagere metriek op het fysieke pad winnen allemaal van een brede tunnelroute. Het zichtbare resultaat is een bron die onbereikbaar is terwijl al het andere werkt. Langere prefixen winnen altijd, dus de winnaar is vaak een hostroute die iemand maanden geleden heeft toegevoegd en vergeten.

Controleer hier ook beide richtingen. Een route naar de serverkant is nodig maar niet voldoende, want het antwoord moet ook via de tunnel terugkomen. Als de ene interne host werkt en de andere niet, zit het verschil meestal in deze tabel en niet in de adapterconfiguratie.

Stap 3: scheid naamopzoeking van diensttoegang

Een toepassing die een share niet opent, kan op een van twee heel verschillende fasen falen. Los de naam op en bereik dan het adres. Als het eerste faalt en het tweede werkt, is de tunnel in orde en de resolver niet:

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

Een geslaagde adrestest plus een mislukte naamtest lokaliseert het probleem in de resolutie, en het tweede commando laat zien of de tunnelinterface überhaupt een server heeft gekregen. Veel clients duwen DNS als onderdeel van de tunnelconfiguratie, en een profiel dat die gepushte opties negeert, laat de machine een resolver gebruiken die de privézone niet ziet.

Behandel een werkend adres niet als de definitieve oplossing. Verbinden via adres omzeilt naamresolutie en kan de serveridentiteitscontrole ondermijnen die de toepassing anders zou uitvoeren. Dat is een beveiligingsregressie vermomd als workaround. Gebruik het om de fout te lokaliseren en herstel daarna de resolutie.

Terugdraaien: bouw DHCP niet opnieuw op voor een getoonde waarde

Als u al bent begonnen de adresdienst te wijzigen, stop dan en controleer of iets van wat u hebt gewijzigd essentieel is. Een scope opnieuw aanmaken, leases opnieuw uitgeven of de pool verplaatsen verandert toestand waarvan andere clients afhangen, en niets daarvan wordt gerechtvaardigd door een hostmasker op een punt-naar-punt-adapter.

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

Voer deze drie uit na elke gerichte wijziging en vergelijk met de vorige run. Het nuttige resultaat is een gedocumenteerd pad naar de bron, niet een adapter waarvan het masker op het kantoor-LAN lijkt.

Schrijf daarna op wat het masker echt betekende, want de volgende persoon opent dezelfde dialoog en trekt dezelfde verkeerde conclusie. Eén zin in de profielnotities, dat de tunnel punt-naar-punt is en de externe subnetten als routes binnenkomen, bespaart de volgende keer het hele onderzoek.