Hvorfor en bred VPN-rute ødelegger noen få offentlige nettsteder

De fleste sider lastes, to eller tre går ut på tid, og nettleseren gir forbindelsen skylden. Nettstedene som feiler, har noe til felles som de som fungerer ikke har: de oppløste adressene deres faller innenfor et prefiks som VPN-en installerte. En rute som er bred nok til å dekke et offentlig område, vil fange trafikk som tunnelen aldri var ment å frakte, og symptomet ser ut som et nettstedsproblem i stedet for en rutingsbeslutning.

Slå opp navnet som feiler, og se deretter på rutetabellen i stedet for nettleseren.

Sammenlign adressen, ikke nettstedets navn

Slå opp adressen klienten faktisk forsøkte, og kontroller deretter hvilken rute som samsvarer med den. En destinasjon innenfor 45.61.20.10 faller under 45.0.0.0/8 hvis det prefikset er til stede, selv om nettstedet selv ikke har noe med tunnelen å gjøre. Å sammenligne den feilende adressen med de installerte prefiksene er en subtraksjonsoppgave, ikke en gjetning.

Windows kan svare på begge halvdeler direkte, og et oppslag viser hvilken grensesnitt og hvilket neste hopp som vant utvalget. Slå opp navnet to ganger hvis nettstedet returnerer flere adresser. Noter hver av dem med ruten som samsvarte. Ulike adresser kan gi ulike svar, og bare én av dem er kanskje det feilende tilfellet.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Les det mest spesifikke samsvarende prefikset, ikke den første linjen som ser kjent ut. En rute som finnes i tabellen beviser ikke at den vant oppslaget; det gjør den lengste treffet. To prefikser kan samsvare med én adresse, og bare én av dem mottar pakken. Taperen blir i tabellen og ser like ekte ut i en liste.

Skriv ned prefikset, grensesnittet og den oppløste adressen. De tre verdiene er hele diagnosen.

Finn ut hvem som installerte ruten

Ruter kommer fra fire steder: den innebygde VPN-profilen, en administrasjonspolicy, et tilkoblingsskript eller en helt annen klient. Å slette den levende oppføringen kan bekrefte relevansen, men den neste tilkoblingen gjenoppretter den fra den lagrede konfigurasjonen, så kilden er det som må endres.

Kontroller rutelisten til profilen først, deretter administrasjonspolicyen, deretter ethvert skript som kjører ved tilkobling. Den rekkefølgen samsvarer med hvor ofte hver av dem viser seg å være ansvarlig. Den holder også endringen i ett lag i stedet for tre.

Les den innebygde klassebaserte atferden nøye

Innebygde Windows-profiler har en dokumentert innstilling, NativeProfile/DisableClassBasedDefaultRoute, som styrer en automatisk rute utledet fra grensesnittadressen. En profiladresse som begynner med 45 kan under den atferden produsere en oppføring 45.0.0.0/8, og det er slik én offentlig adresse fanger et helt klasse-A-område.

Egenskapsnavnet innbyr til feil lesing: satt til true deaktiverer det utledningen, og false aktiverer den. Det er heller ikke samme objekt som en standardrute, og det styrer ikke tredjepartsklienter som installerer sine egne prefikser.

Hvis det er utledningen som er den påviste årsaken, retter du profilen via administrasjonseieren og oppgir de tiltenkte private prefiksene eksplisitt. Hvis et skript la til oppføringen, reparerer du skriptet. Å erstatte én uforklart bred rute med en annen endrer symptomet uten å svare på spørsmålet.

Reparer kilden, og kontroller deretter begge stiene på nytt

Etter endringen kobler du til på nytt og gjentar oppslaget for et feilende offentlig nettsted og for en ressurs som må bruke tunnelen. Det første skal nå løses til det fysiske grensesnittet, og det andre skal fortsatt velge VPN-en. Ikke stopp ved den første suksessen; en rettelse som også bryter privat tilgang, har byttet én feil mot en annen.

Gå gjennom serverens adresseplan samtidig. En pool som overlapper offentlig rom, forårsaker denne typen problem gang på gang. Et område operatøren valgte med vilje fortjener en annen samtale, ikke automatisk omnummerering.

Å øke MTU-en eller tømme DNS vil ikke rette et prefiks som fortsatt sender den adressen inn i tunnelen. Test utvalget først, deretter stien.