Večina strani se naloži, dve ali tri potečejo, brskalnik pa krivi povezavo. Spletna mesta, ki ne uspejo, imajo nekaj skupnega, česar delujoča nimajo: njihovi razrešeni naslovi padejo v predpono, ki jo je namestil VPN. Pot, dovolj široka, da pokrije javno območje, bo zajela promet, ki ga tunel nikoli ni bil namenjen prenašati, simptom pa je videti kot težava spletnega mesta, ne kot odločitev o usmerjanju.

Razrešite ime, ki ne uspe, nato poglejte v usmerjevalno tabelo in ne v brskalnik.

Primerjajte naslov, ne imena spletnega mesta

Poiščite naslov, ki ga je odjemalec dejansko poskusil, nato preverite, katera pot se ujema z njim. Cilj znotraj 45.61.20.10 pade pod 45.0.0.0/8, če je ta predpona prisotna, tudi če spletno mesto samo nima nič z tunelom. Primerjava neuspešnega naslova z nameščenimi predponami je naloga odštevanja, ne ugibanje.

Windows lahko neposredno odgovori na obe polovici, iskanje pa pokaže, kateri vmesnik in kateri naslednji skok sta zmagala pri izbiri. Razrešite ime dvakrat, če spletno mesto vrne več naslovov. Zapišite vsakega s potjo, ki se je ujemala. Različni naslovi lahko dajo različne odgovore in le eden od njih je morda neuspešni primer.

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

Berite najbolj specifično ujemajočo se predpono, ne prve vrstice, ki se zdi znana. Pot v tabeli ne dokazuje, da je zmagala pri iskanju; to stori najdaljše ujemanje. Dve predponi se lahko ujemata z enim naslovom in le ena od njiju prejme paket. Poraženec ostane v tabeli in je na seznamu videti enako resničen.

Zapišite predpono, njen vmesnik in razrešeni naslov. Te tri vrednosti so celotna diagnoza.

Ugotovite, kdo je namestil pot

Poti prihajajo s štirih mest: iz izvornega profila VPN, iz upravljavske politike, iz skripta za povezavo ali iz povsem drugega odjemalca. Brisanje aktivnega vnosa lahko potrdi njegov pomen, vendar naslednja povezava ga znova ustvari iz shranjene konfiguracije, zato je treba spremeniti vir.

Najprej preverite seznam poti profila, nato upravljavsko politiko, nato kateri koli skript, ki se izvaja ob povezavi. Ta vrstni red ustreza temu, kako pogosto se kateri izkaže za odgovornega. Spremembo tudi zadrži v enem sloju namesto v treh.

Pozorno preberite izvorno vedenje na podlagi razredov

Izvorni profili Windows imajo dokumentirano nastavitev NativeProfile/DisableClassBasedDefaultRoute, ki nadzira samodejno pot, izpeljano iz naslova vmesnika. Naslov profila, ki se začne s 45, lahko pri tem vedenju ustvari vnos 45.0.0.0/8, in tako en javni naslov zajame celotno območje razreda A.

Ime lastnosti vabi k napačnemu branju: nastavitev na true izklopi izpeljavo, false pa jo vklopi. Ni niti isti objekt kot privzeta pot in ne upravlja odjemalcev tretjih oseb, ki nameščajo svoje predpone.

Če je izpeljava dokazan vzrok, popravite profil prek njegovega upravljavskega lastnika in izrecno navedite predvidene zasebne predpone. Če je vnos dodal skript, popravite skript. Zamenjava ene nerazložene široke poti z drugo spremeni simptom, ne da bi odgovorila na vprašanje.

Popravite vir in nato znova preverite obe poti

Po spremembi se znova povežite in ponovite iskanje za neuspešno javno spletno mesto in za vir, ki mora uporabljati tunel. Prvi bi se moral zdaj razrešiti na fizični vmesnik, drugi pa bi moral še vedno izbrati VPN. Ne ustavite se pri prvem uspehu; popravek, ki pokvari tudi zasebni dostop, je zamenjal eno napako za drugo.

Hkrati preglejte načrt naslovov strežnika. Skupina, ki se prekriva z javnim prostorom, povzroča to vrsto težave znova in znova. Obseg, ki ga je operater izbral namerno, si zasluži drug pogovor, ne samodejnega preštevilčenja.

Povečanje MTU ali čiščenje DNS ne bo popravilo predpone, ki ta naslov še vedno usmerja v tunel. Najprej preizkusite izbiro, nato pot.

Sorodni članki