Windows-VPN wys 255.255.255.255: is die masker verkeerd?

Die tonnel verbind, jy maak die adapterbesonderhede oop, en die masker wys 255.255.255.255. Vergeleke met die 255.255.255.0 van die kantoor-LAN lyk dit stukkend, en dit is gewoonlik waar die fout begin. Op ’n punt-tot-punt-skakel is ’n gasheermasker die korrekte beskrywing van die plaaslike eindpunt, en die afgeleë netwerke kom in as roetes eerder as as ’n gekoppelde subnet. Die prosedure hieronder skei die twee vrae sodat jy nie ’n werkende DHCP-omvang herbou net om ’n vertoonde waarde reg te maak nie.

’n Punt-tot-punt-skakel is nie ’n Ethernet-segment nie

’n Ethernet-koppelvlak het ’n subnetmasker nodig omdat elke adres in daardie reeks moontlik op dieselfde kabel bereikbaar is. ’n Tonnel in PPP-styl het presies een peer aan die ander kant. Daar is geen uitsaaidomein, geen ARP en geen rede waarom die plaaslike adres ’n reeks sou beskryf nie.

Die adresonderhandeling vir daardie model word in RFC 1332 gedefinieer, wat dek hoe die twee kante oor hul adresse ooreenkom. Wat dit nie doen nie, is om die kantoor-LAN as ’n direk gekoppelde netwerk aan die kliënt te gee. Die kliënt leer waar die kantoor is deur roetes oor die skakel te installeer, en dit is daardie roetes wat werklik die bereikbaarheid bepaal.

Dit beteken nie dat elke masker wat jy sien korrek is nie. ’n Verkeerd opgestelde kliënt kan ook vreemde adressering lewer. Die punt is smaller: ’n gasheermasker op hierdie tipe adapter word verwag, so dit is op sigself nie bewys van ’n fout nie.

Stap 1: bevestig die koppelvlakmodel

Kyk wat die adapter is voordat jy beoordeel wat dit sê. Die beskrywingstring identifiseer die drywer, en die voorvoegsellengte op die toegewysde adres bevestig wat die kliënt onderhandel het:

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

Die derde opdrag is die een wat die meeste argumente besleg. ’n Lae maksimum transmissie-eenheid is kenmerkend van ’n ingekapselde skakel, terwyl ’n Ethernet-agtige waarde op ’n ander virtuele adaptermodel dui. As die beskrywing ’n PPP- of RAS-drywer noem en die voorvoegsel is 32, sien jy presies die ontwerp hierbo beskryf en kan jy ophou jou oor die masker te bekommer.

Stap 2: lees die roete vir die bestemming wat misluk

Bereikbaarheid word per bestemming bepaal, en ’n enkele gekoppelde koppelvlak sê niks daaroor nie. Vra die roetetabel direk oor die adres wat die gebruiker werklik probeer bereik:

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

Find-NetRoute is die direkte antwoord: dit noem die koppelvlak en die bronadres wat die stelsel vir daardie bestemming sou gebruik. As dit die tonnel teruggee, gaan verkeer na daardie gasheer deur die tonnel en was die masker nooit die probleem nie.

As dit die fisiese adapter teruggee, vergelyk die twee kandidaatroetes en hul maatstawwe. ’n Spesifieke plaaslike roete, ’n oorblyfsel van ’n ander kliënt of ’n laer maatstaf op die fisiese pad wen almal bo ’n breë tonnelroete. Die sigbare resultaat is ’n hulpbron wat onbereikbaar is terwyl alles anders werk. Langer voorvoegsels wen altyd, so die wenner is dikwels ’n gasheerroete wat iemand maande gelede bygevoeg en vergeet het.

Kontroleer ook beide rigtings terwyl jy hier is. ’n Roete na die bedienerkant is nodig maar nie voldoende nie, want die antwoord moet ook deur die tonnel terugkom. Wanneer een interne gasheer werk en ’n ander nie, lê die verskil gewoonlik in hierdie tabel en nie in die adapteropstelling nie.

Stap 3: skei naamopsoeking van dienstoegang

’n Toepassing wat nie ’n deel oopmaak nie, kan by een van twee baie verskillende stadiums misluk. Los die naam op en bereik dan die adres. As die eerste misluk en die tweede werk, is die tonnel reg en die resolveerder nie:

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

’n Suksesvolle adrestoets plus ’n mislukte naamtoets lokaliseer die probleem by die oplossing, en die tweede opdrag wys of die tonnelkoppelvlak hoegenaamd ’n bediener ontvang het. Baie kliënte stoot DNS as deel van die tonnelopstelling, en ’n profiel wat daardie gestootde opsies ignoreer, laat die masjien ’n resolveerder gebruik wat nie die private sone sien nie.

Moenie ’n werkende adres as die permanente oplossing beskou nie. Om per adres te verbind omseil naamoplossing en kan die bediener-identiteitskontrole verydel wat die toepassing andersins sou doen. Dit is ’n sekuriteitsregressie vermom as ’n tydelike oplossing. Gebruik dit om die fout te lokaliseer en herstel dan die oplossing.

Terugrol: moenie DHCP herbou oor ’n vertoonde waarde nie

As jy al begin het om die adresdiens te verander, stop en kyk of enigiets wat jy verander het, dragend is. Om ’n omvang te herskep, huurkontrakte weer uit te reik of die poel te skuif verander toestand waarvan ander kliënte afhanklik is, en niks daarvan word deur ’n gasheermasker op ’n punt-tot-punt-adapter geregverdig nie.

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

Voer hierdie drie uit ná enige gerigte verandering en vergelyk met die vorige lopie. Die nuttige uitkoms is ’n gedokumenteerde pad na die hulpbron, nie ’n adapter waarvan die masker soos die kantoor-LAN lyk nie.

Skryf dan neer wat die masker werklik beteken het, want die volgende persoon maak dieselfde dialoog oop en kom tot dieselfde verkeerde gevolgtrekking. Een sin in die profielnotas, dat die tonnel punt-tot-punt is en die afgeleë subnette as roetes inkom, spaar die hele ondersoek die volgende keer.