Waarom 'n breë VPN-roete 'n paar openbare werwe breek

Die meeste bladsye laai, twee of drie verstryk, en die blaaier blameer die verbinding. Die werwe wat faal, het iets gemeen wat die werkendes nie het nie: hul opgeloste adresse val binne 'n voorvoegsel wat die VPN geïnstalleer het. 'n Roete wat wyd genoeg is om 'n openbare reeks te dek, sal verkeer vasvang wat die tonnel nooit bedoel was om te dra nie, en die simptoom lyk soos 'n webwerfprobleem eerder as 'n roetebesluit.

Los die falende naam op en kyk dan na die roetetabel eerder as na die blaaier.

Vergelyk die adres, nie die webwerfnaam nie

Soek die adres op wat die kliënt werklik probeer het en kyk dan watter roete daarby pas. 'n Bestemming binne 45.61.20.10 val onder 45.0.0.0/8 as daardie voorvoegsel teenwoordig is, selfs al het die webwerf self niks met die tonnel te doen nie. Om die falende adres met die geïnstalleerde voorvoegsels te vergelyk, is 'n aftrekprobleem, nie 'n raaiskoot nie.

Windows kan albei helftes direk beantwoord, en 'n opsoeking wys watter koppelvlak en volgende hop die keuse gewen het. Los die naam twee keer op as die werf verskeie adresse teruggee. Teken elkeen aan saam met die roete wat daarby gepas het. Verskillende adresse kan verskillende antwoorde lewer, en net een daarvan is dalk die falende geval.

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

Lees die mees spesifieke ooreenstemmende voorvoegsel, nie die eerste reël wat bekend lyk nie. 'n Roete wat in die tabel voorkom, bewys nie dat dit die opsoeking gewen het nie; die langste passing doen dit. Twee voorvoegsels kan by een adres pas, en net een van hulle ontvang die pakket. Die verloorder bly in die tabel en lyk net so eg in 'n lys.

Skryf die voorvoegsel, sy koppelvlak en die opgeloste adres neer. Daardie drie waardes is die hele diagnose.

Vind wie die roete geïnstalleer het

Roetes kom van vier plekke: die ingeboude VPN-profiel, 'n bestuursbeleid, 'n verbindingskrip of 'n heeltemal ander kliënt. Om die lewende inskrywing te verwyder, kan sy relevansie bevestig, maar die volgende verbinding herskep dit uit die gestoorde konfigurasie, so dit is die bron wat moet verander.

Kyk eerste na die profiel se roetelys, dan na die bestuursbeleid, dan na enige skrip wat by verbinding loop. Daardie volgorde stem ooreen met hoe dikwels elkeen verantwoordelik blyk te wees. Dit hou ook die verandering beperk tot een laag eerder as drie.

Lees die ingeboude klasgebaseerde gedrag noukeurig

Inheemse Windows-profiele het 'n gedokumenteerde instelling, NativeProfile/DisableClassBasedDefaultRoute, wat 'n outomatiese roete beheer wat uit die koppelvlakadres afgelei word. 'n Profieladres wat met 45 begin, kan onder daardie gedrag 'n 45.0.0.0/8-inskrywing lewer, en dit is hoe 'n enkele openbare adres 'n hele klas-A-reeks vasvang.

Die eiendomsnaam nooi die verkeerde lesing: om dit op true te stel, skakel die afleiding af, en false skakel dit aan. Dit is ook nie dieselfde objek as 'n verstekroete nie, en dit beheer nie derdeparty-kliënte wat hul eie voorvoegsels installeer nie.

As die afleiding die bewese oorsaak is, herstel die profiel deur sy bestuurseienaar en verskaf die beoogde private voorvoegsels eksplisiet. As 'n skrip die inskrywing bygevoeg het, herstel die skrip. Om een onverklaarde wye roete deur 'n ander te vervang, verander die simptoom sonder om die vraag te beantwoord.

Herstel die bron en kontroleer dan albei paaie weer

Herverbind na die verandering en herhaal die opsoeking vir 'n falende openbare werf en vir 'n hulpbron wat die tonnel moet gebruik. Die eerste behoort nou na die fisiese koppelvlak op te los, en die tweede behoort steeds die VPN te kies. Moenie by die eerste sukses stop nie; 'n regstelling wat private toegang ook breek, het een fout vir 'n ander verruil.

Hersien terselfdertyd die bediener se adresplan. 'n Poel wat met openbare ruimte oorvleuel, veroorsaak hierdie klas probleem herhaaldelik. 'n Reeks wat die operateur doelbewus gekies het, verdien 'n ander gesprek, nie 'n outomatiese hernommering nie.

Om die MTU te verhoog of DNS te spoel, sal nie 'n voorvoegsel regstel wat daardie adres steeds in die tonnel lei nie. Toets eers die keuse, dan die pad.