Proč široká trasa VPN rozbíjí několik veřejných webů

Většina stránek se načte, dvě nebo tři vyprší a prohlížeč viní připojení. Weby, které selhávají, mají něco společného, co funkční nemají: jejich přeložené adresy spadají do prefixu, který nainstalovala VPN. Trasa dost široká na pokrytí veřejného rozsahu zachytí provoz, který tunel nikdy neměl přenášet, a příznak vypadá jako problém webu, nikoli jako rozhodnutí o směrování.

Přeložte selhávající název a pak se podívejte do směrovací tabulky, ne do prohlížeče.

Porovnávejte adresu, ne název webu

Vyhledejte adresu, kterou klient skutečně zkoušel, a pak zjistěte, která trasa jí odpovídá. Cíl uvnitř 45.61.20.10 spadá pod 45.0.0.0/8, pokud je tento prefix přítomen, i když samotný web nemá s tunelem nic společného. Porovnání selhávající adresy s nainstalovanými prefixy je úloha na odčítání, ne hádání.

Windows umí odpovědět na obě poloviny přímo a vyhledání ukáže, které rozhraní a který další skok vyhrály výběr. Pokud web vrací několik adres, přeložte název dvakrát. Zapište každou z nich s trasou, která jí odpovídala. Různé adresy mohou dávat různé odpovědi a jen jedna z nich může být selhávajícím případem.

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

Čtěte nejkonkrétnější odpovídající prefix, ne první řádek, který vypadá povědomě. Trasa přítomná v tabulce nedokazuje, že vyhrála vyhledání; to dělá nejdelší shoda. Dva prefixy mohou odpovídat jedné adrese a jen jeden z nich paket přijme. Poražený zůstává v tabulce a v seznamu vypadá stejně skutečně.

Zapište prefix, jeho rozhraní a přeloženou adresu. Tyto tři hodnoty jsou celá diagnóza.

Zjistěte, kdo trasu nainstaloval

Trasy přicházejí ze čtyř míst: z nativního profilu VPN, z řídicí zásady, z připojovacího skriptu nebo ze zcela jiného klienta. Smazání živého záznamu může potvrdit jeho význam, ale příští připojení jej znovu vytvoří z uložené konfigurace, takže měnit se musí zdroj.

Nejprve zkontrolujte seznam tras profilu, potom řídicí zásadu, potom jakýkoli skript spouštěný při připojení. Toto pořadí odpovídá tomu, jak často se který ukáže být odpovědný. Také udržuje změnu v jedné vrstvě místo tří.

Pozorně si přečtěte nativní chování založené na třídách

Nativní profily Windows mají dokumentované nastavení NativeProfile/DisableClassBasedDefaultRoute, které řídí automatickou trasu odvozenou z adresy rozhraní. Adresa profilu začínající na 45 může při tomto chování vytvořit záznam 45.0.0.0/8, a tak jedna veřejná adresa zachytí celý rozsah třídy A.

Název vlastnosti svádí k chybnému čtení: nastavení na true odvození vypne a false jej zapne. Není to ani stejný objekt jako výchozí trasa a neřídí klienty třetích stran, kteří instalují vlastní prefixy.

Pokud je odvození prokázanou příčinou, opravte profil prostřednictvím jeho správce a výslovně uveďte zamýšlené privátní prefixy. Pokud záznam přidal skript, opravte skript. Nahrazení jedné nevysvětlené široké trasy jinou mění příznak, aniž by odpovědělo na otázku.

Opravte zdroj a pak znovu zkontrolujte obě cesty

Po změně se znovu připojte a zopakujte vyhledání pro selhávající veřejný web a pro zdroj, který musí procházet tunelem. První by se nyní měl přeložit na fyzické rozhraní a druhý by měl stále volit VPN. Nezastavujte se u prvního úspěchu; oprava, která zároveň rozbije privátní přístup, vyměnila jednu závadu za jinou.

Současně zkontrolujte adresní plán serveru. Pula překrývající se s veřejným prostorem způsobuje tento druh problému znovu a znovu. Rozsah, který operátor zvolil záměrně, si zaslouží jinou konverzaci, ne automatické přečíslování.

Zvýšení MTU nebo vymazání DNS neopraví prefix, který tuto adresu stále posílá do tunelu. Nejprve otestujte výběr, potom cestu.