Hvorfor en bred VPN-rute brækker nogle få offentlige websteder

De fleste sider indlæses, to eller tre går i timeout, og browseren giver forbindelsen skylden. De websteder, der fejler, har noget til fælles, som de fungerende ikke har: deres opløste adresser falder inden for et præfiks, som VPN'et installerede. En rute, der er bred nok til at dække et offentligt område, vil fange trafik, som tunnelen aldrig var beregnet til at bære, og symptomet ligner et webstedsproblem snarere end en routingbeslutning.

Opløs det fejlende navn, og se derefter på routingtabellen i stedet for på browseren.

Sammenlign adressen, ikke webstedets navn

Slå den adresse op, som klienten faktisk forsøgte, og kontroller derefter, hvilken rute der matcher den. En destination inden for 45.61.20.10 falder under 45.0.0.0/8, hvis det præfiks er til stede, selv om webstedet selv intet har med tunnelen at gøre. At sammenligne den fejlende adresse med de installerede præfikser er en subtraktionsopgave, ikke et gæt.

Windows kan svare på begge halvdele direkte, og et opslag viser, hvilken grænseflade og næste hop der vandt udvælgelsen. Opløs navnet to gange, hvis webstedet returnerer flere adresser. Notér hver af dem sammen med den rute, der matchede. Forskellige adresser kan give forskellige svar, og kun én af dem er måske det fejlende tilfælde.

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

Læs det mest specifikke matchende præfiks, ikke den første linje, der ser bekendt ud. En rute, der findes i tabellen, beviser ikke, at den vandt opslaget; det gør det længste match. To præfikser kan matche én adresse, og kun ét af dem modtager pakken. Taberen bliver i tabellen og ser lige så virkelig ud i en liste.

Skriv præfikset, dets grænseflade og den opløste adresse ned. De tre værdier er hele diagnosen.

Find ud af, hvem der installerede ruten

Ruter kommer fra fire steder: den indbyggede VPN-profil, en administrationspolitik, et forbindelsesskript eller en helt anden klient. At slette den levende post kan bekræfte dens relevans, men den næste forbindelse genskaber den ud fra den gemte konfiguration, så det er kilden, der skal ændres.

Tjek først profilens ruteliste, derefter administrationspolitikken, derefter ethvert script, der kører ved forbindelse. Den rækkefølge svarer til, hvor ofte hver af dem viser sig ansvarlig. Den holder også ændringen afgrænset til ét lag i stedet for tre.

Læs den indbyggede klassebaserede adfærd omhyggeligt

Indbyggede Windows-profiler har en dokumenteret indstilling, NativeProfile/DisableClassBasedDefaultRoute, som styrer en automatisk rute, der udledes af grænsefladeadressen. En profiladresse, der begynder med 45, kan under den adfærd producere en 45.0.0.0/8-post, og det er sådan en enkelt offentlig adresse fanger et helt klasse-A-område.

Egenskabsnavnet indbyder til den forkerte læsning: sat til true deaktiverer det udledningen, og false aktiverer den. Det er heller ikke det samme objekt som en standardrute, og det styrer ikke tredjepartsklienter, der installerer deres egne præfikser.

Hvis udledningen er den påviste årsag, så ret profilen via dens administrative ejer, og angiv de tilsigtede private præfikser eksplicit. Hvis et script tilføjede posten, så reparer scriptet. At erstatte én uforklaret bred rute med en anden ændrer symptomet uden at besvare spørgsmålet.

Reparer kilden, og tjek derefter begge stier igen

Genopret forbindelsen efter ændringen, og gentag opslaget for et fejlende offentligt websted og for en ressource, der skal bruge tunnelen. Det første bør nu opløses til den fysiske grænseflade, og det andet bør stadig vælge VPN'et. Stop ikke ved den første succes; en rettelse, der også brækker privat adgang, har byttet én fejl for en anden.

Gennemgå serverens adresseplan samtidig. En pulje, der overlapper offentligt rum, forårsager denne type problem igen og igen. Et område, som operatøren valgte med vilje, fortjener en anden samtale, ikke en automatisk omnummerering.

At hæve MTU'en eller tømme DNS vil ikke rette et præfiks, der stadig sender den adresse ind i tunnelen. Test udvælgelsen først, og derefter stien.