Proč jedna podsíť stále obchází výchozí trasu VPN

Přepnete VPN do plného tunelu, většina provozu poslechne, a pak jedna adresa odpoví přímo — tiskárna, NAS, jump host na 10.x. Nabízející se vysvětlení je, že tunel uniká, takže snížíte metriku výchozí trasy a nic se nezmění. Ten neúspěšný pokus je vodítko: výchozí trasa je záložní varianta, ne rozsudek. Vyhledání trasy bere nejdelší odpovídající prefix, dříve než vůbec porovná metriky, takže /24 dál vyhrává nad /0, ať k kterékoli z nich připojíte jakékoli číslo. Jakmile je toto pořadí jasné, únik je obvykle trasa, kterou někdo nainstaloval záměrně, nebo prefix, který klient nikdy neměl v úmyslu pokrýt.

Co výchozí trasa skutečně slibuje

0.0.0.0/0 odpovídá každému cíli IPv4 s nulovou specificitou bitů. Existuje proto, aby se host dostal na cokoli, co jeho tabulka nepopisuje lépe. Trasa na 192.168.1.0/24 nese 24 odpovídajících bitů, takže pro 192.168.1.40 vyhrává dřív, než kdokoli porovná metriky, administrativní vzdálenost nebo jakkoli klient nazve své pole priority. Stejné pravidlo platí v Linux FIB, v routovací tabulce Windows a ve zásobníku BSD za macOS.

V běžné LAN je toto chování výhoda. Lokální podsíť je připojena přímo, tiskárna funguje dál, zatímco tunel nese vaše prohlížení, a nic není špatně nakonfigurováno. Otázka, kterou stojí za to si položit, není, proč ta jedna adresa jde přímo, ale který prefix v které tabulce jí odpovídá a kdo ho tam dal.

Poloviční výchozí trasy aneb proč může výchozí záznam vypadat nedotčeně

Nejčistší příklad je redirect-gateway def1 v OpenVPN. Místo aby smazal vaši výchozí trasu a nahradil ji, přidá 0.0.0.0/1 a 128.0.0.0/1. Společně dvojice pokrývá celý IPv4, každý prefix je delší než /0 a oba překonávají výchozí trasu routeru, aniž by ji odstranily. Spusťte poté výpis tras a původní výchozí trasa je pořád tam, pořád ukazuje na vaši bránu; jen se nikdy nevybere pro internetové cíle.

wg-quick z WireGuardu dosahuje stejného výsledku pomocí politického routování. Když AllowedIPs pokrývá 0.0.0.0/0, vytvoří si vlastní tabulku, posílá tam označené pakety a přidá pravidlo, které ignoruje prefix nulové délky hlavní tabulky. Hlavní tabulka si ponechá svůj výchozí záznam a pravidla rozhodnou, že se tabulka tunelu pro provoz, který rozhraní vlastní, dotazuje první.

Oba návrhy potřebují právě jednu trasu mimo tunel: hostitelskou trasu na vlastní adresu serveru VPN přes původní bránu. Bez ní by se klient pokoušel nést pakety, které staví tunel, uvnitř tunelu, a spojení by se nikdy nedokončilo. Trasa, která není tunelová, je tedy ve vaší tabulce normální i u přísného profilu plného tunelu. Trasy, u kterých stojí za to pochybovat, jsou ty, které pokrývají cíle, na kterých vám skutečně záleží.

Metriky rozhodují remízy, prefixy rozhodují vítěze

Metriky se porovnávají jen mezi kandidáty, kteří odpovídají cíli stejně dobře. V Linuxu ip route get 10.20.5.9 vypíše vítěze spolu s jeho tabulkou a ip route show table all vypíše kandidáty, včetně případných polovičních výchozích tras a každé tabulky, na kterou ukazuje nějaké pravidlo. Ve Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 vrací vybranou trasu a zdrojovou adresu, zatímco Get-NetRoute ukazuje surovou tabulku — ale efektivní cena je metrika trasy plus metrika rozhraní, takže pomalý adaptér může prohrát remízu, kterou zdánlivě vyhrává.

Tři případy pokrývají většinu toho, co uvidíte:

• Stejný cíl, /24 proti /0: /24 vyhrává na délku prefixu, ať metriky říkají cokoli.
• Stejný cíl, dvě /24 s různými metrikami: vyhrává nižší efektivní metrika.
• Stejný cíl, dvě tabulky, jedna vybraná pravidlem zásad: pravidlo nejdřív vybere tabulku a porovnání prefixů probíhá uvnitř ní.

Třetí případ je místo, kde končí většina těchto hlášení. Linuxové ip rule nebo filtr provozu VPN ve Windows může poslat provoz do tabulky, která nikdy nedržela výchozí trasu tunelu, a hlavní tabulka přitom celou dobu vypadá bezchybně.

Kdo obvykle obcházení vlastní

Začněte profilem, ne tabulkou. Konfigurace split-tunnel a nastavení VPN pro jednotlivé aplikace záměrně nechávají pojmenované prefixy mimo tunel; pracovní profil, který chrání jednu privátní podsíť a nechává běžné prohlížení jít přímo, se chová tak, jak byl navržen, a jeho přepsání porušuje zásadu, kterou měl prosazovat. Pokyny k routování VPN od Microsoftu staví stejnou hranici mezi provozem nuceným do tunelu a výslovnými výjimkami, což z nich dělá užitečnou křížovou kontrolu, než cokoli upravíte.

Dále hledejte zbytky. Trasa ukazující na rozhraní, které už neexistuje, nebo na adresu z předchozí sítě, se objeví poté, co přijdou a odejdou dokovací stanice, USB adaptéry a mosty kontejnerů. Smazat ji jednou není konec: profily připojení NetworkManageru, soubory netplan a trvalé trasy Windows ji při dalším připojení nebo startu nainstalují znovu, takže než cokoli upravíte, najděte soubor nebo profil, který ji vlastní.

Poté zkontrolujte IPv6 samostatně. ip -6 route a Get-NetRoute -AddressFamily IPv6 drží oddělený stav, oddělené výchozí trasy a oddělené chování klienta. Audit pouze IPv4 neříká nic o hostiteli s duálním zásobníkem, který tiše preferuje nativní cestu IPv6, a jen to samo může způsobit, že klient vypadá jako split-tunnel.

Potvrďte vlastním tokem aplikace

Zaznamenejte cíl, který aplikace skutečně používá, a pak se systému zeptejte na cestu, kterou by se vydal ze zdrojové adresy, k níž se ta aplikace váže. ip route get 10.20.5.9 from 192.168.1.40 na to odpovídá v Linuxu; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus lokální adresa to dělá ve Windows. Porovnejte výsledek s tím, co tvrdí profil. Stránka veřejné IP v prohlížeči testuje jeden cíl na jednom protokolu a o privátní adrese, která stížnost spustila, neříká nic.

Opravte nejužší objekt, který rozdíl vysvětluje. Pokud je výjimka schválená, zapište prefix a nechte ho být; pokud ne, odstraňte trasu nebo přidejte výslovnou užší trasu tunelem, místo abyste snižovali metriku výchozí trasy. Snížení metriky nemůže předstihnout delší prefix a úprava výchozí trasy, zatímco internetovou cestu vlastní dvě trasy /1, také nic nezmění.

Poté tunel znovu připojte a stejný dotaz zopakujte. Klienti při každém připojení reinstalují trasy, takže změna, která vydrží jen do dalšího handshaku, není otestovaná. Pokud se cesta stále rozchází, zbývajícími podezřelými jsou pravidlo zásad, druhá tabulka nebo filtr na straně klienta — ne výchozí trasa.

• Pojmenujte cíl a zdrojovou adresu, které aplikace skutečně používá.
• Vypište vítěznou trasu pomocí ip route get nebo Find-NetRoute.
• Zkontrolujte, zda internetovou cestu vlastní dvojice /1, nebo tabulka zásad.
• Vypište každý prefix delší než /0, který odpovídá cíli.
• Zopakujte kontrolu IPv6 samostatně.
• Vystopujte zbývající trasu zpět k souboru, profilu nebo filtru, který ji instaluje.
• Znovu se připojte a znovu spusťte dotaz, než to označíte za opravené.

Pokud všech sedm souhlasí s profilem, tunel dělá přesně to, k čemu byl nakonfigurován, a oprava patří do profilu, ne do metriky.