Prečo jedna podsiet stále obchádza predvolenú trasu VPN

Prepnete VPN na plný tunel, väčšina prevádzky poslúchne, a potom jedna adresa odpovie priamo — tlačiareň, NAS, skokový host v 10.x. Zjavné čítanie je, že tunel uniká, takže znížite metriku predvolenej trasy a nič sa nezmení. Ten neúspešný pokus je stopa: predvolená trasa je záložný variant, nie rozsudok. Vyhľadanie trasy berie najdlhší zodpovedajúci prefix skôr, než vôbec porovná metriky, takže /24 ďalej vyhráva nad /0, akékoľvek číslo k nim pripojíte. Keď je toto poradie jasné, únik je zvyčajne trasa, ktorú niekto nainštaloval zámerne, alebo prefix, ktorý klient nikdy nemal v úmysle pokryť.

Čo predvolená trasa skutočne sľubuje

0.0.0.0/0 zodpovedá každému cieľu IPv4 s nulovou špecifickosťou bitov. Existuje preto, aby sa host dostal na čokoľvek, čo jeho tabuľka neopisuje lepšie. Trasa na 192.168.1.0/24 nesie 24 zodpovedajúcich bitov, takže pre 192.168.1.40 vyhráva skôr, než ktokoľvek porovná metriky, administratívnu vzdialenosť alebo čokoľvek, čo klient nazýva poľom priority. Rovnaké pravidlo platí v Linux FIB, v smerovacej tabuľke Windows a v zásobníku BSD za macOS.

V bežnej LAN je toto správanie výhoda. Lokálna podsiet je pripojená priamo, tlačiareň funguje ďalej, zatiaľ čo tunel nesie vaše prehliadanie, a nič nie je nesprávne nakonfigurované. Otázka, ktorú sa oplatí položiť, nie je, prečo tá jedna adresa ide priamo, ale ktorý prefix v ktorej tabuľke jej zodpovedá a kto ho tam umiestnil.

Polovičné predvolené trasy, alebo prečo môže predvolený záznam vyzerať nedotknuto

Najčistejší príklad je redirect-gateway def1 v OpenVPN. Namiesto vymazania a nahradenia predvolenej trasy pridáva 0.0.0.0/1 a 128.0.0.0/1. Spolu pár pokrýva celý IPv4, každý prefix je dlhší ako /0 a oba prekonávajú predvolenú trasu smerovača, pričom ju nechávajú na mieste. Spustite potom zoznam trás a pôvodná predvolená trasa je stále tam, stále ukazuje na váš gateway; jednoducho sa nikdy nevyberie pre internetové ciele.

wg-quick z WireGuardu dosahuje rovnaký výsledok cez politické smerovanie. Keď AllowedIPs pokrýva 0.0.0.0/0, vytvorí si vlastnú tabuľku, posiela tam označené pakety a pridá pravidlo, ktoré ignoruje prefix nulovej dĺžky hlavnej tabuľky. Hlavná tabuľka si ponecháva predvolený záznam a pravidlá rozhodujú, že pre prevádzku, ktorú vlastní rozhranie, sa najprv pýta tunelová tabuľka.

Oba návrhy potrebujú presne jednu trasu mimo tunela: trasu hosta na vlastnú adresu VPN servera cez pôvodnú bránu. Bez nej by sa klient pokúšal prenášať pakety, ktoré stavajú tunel, vnútri tunela, a spojenie by sa nikdy nedokončilo. Trasa, ktorá nie je tunelová, je preto vo vašej tabuľke normálna aj pri prísnom profile plného tunela. Trasy, ktoré stoja za spochybnenie, sú tie, ktoré pokrývajú ciele, na ktorých vám skutočne záleží.

Metriky rozhodujú remízy, prefixy rozhodujú víťazov

Metriky sa porovnávajú len medzi kandidátmi, ktorí rovnako dobre zodpovedajú cieľu. V Linuxe ip route get 10.20.5.9 vypíše víťaza spolu s jeho tabuľkou a ip route show table all vypíše kandidátov vrátane akýchkoľvek polovičných predvolených trás a každej tabuľky, na ktorú ukazuje pravidlo. Vo Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 vracia vybranú trasu a zdrojovú adresu, zatiaľ čo Get-NetRoute zobrazuje surovú tabuľku — ale efektívne náklady sú metrika trasy plus metrika rozhrania, takže pomalý adaptér môže prehrať remízu, ktorú zdanlivo vyhráva.

Tri prípady pokrývajú väčšinu toho, čo uvidíte:

• Rovnaký cieľ, /24 proti /0: /24 vyhráva dĺžkou prefixu, nech metriky hovoria čokoľvek.
• Rovnaký cieľ, dve /24 s rôznymi metrikami: vyhráva nižšia efektívna metrika.
• Rovnaký cieľ, dve tabuľky, jedna vybraná pravidlom politiky: pravidlo najprv vyberie tabuľku a porovnanie prefixov prebehne v nej.

Tretí prípad je miesto, kde končí väčšina týchto hlásení. Linuxové ip rule alebo filter prevádzky VPN vo Windows môže poslať prevádzku do tabuľky, ktorá nikdy neobsahovala predvolenú trasu tunela, a hlavná tabuľka pritom celý čas vyzerá bezchybne.

Kto zvyčajne vlastní obchádzanie

Začnite profilom, nie tabuľkou. Konfigurácie split-tunnel a nastavenia VPN pre jednotlivé aplikácie zámerne nechávajú pomenované prefixy mimo tunela; pracovný profil, ktorý chráni jednu privátnu podsiet a necháva bežné prehliadanie ísť priamo, sa správa tak, ako bol navrhnutý, a jeho prepísanie porušuje politiku, ktorú mal presadzovať. Usmernenie Microsoftu k smerovaniu VPN kreslí rovnakú hranicu medzi prevádzkou nútenou do tunela a výslovnými výnimkami, čo z neho robí užitočnú krížovú kontrolu pred akoukoľvek úpravou.

Potom hľadajte zvyšky. Trasa ukazujúca na rozhranie, ktoré už neexistuje, alebo na adresu z predchádzajúcej siete, sa objaví po príchode a odchode dokovacích staníc, USB adaptérov a mostov kontajnerov. Raz ju vymazať nie je koniec: profily pripojenia NetworkManager, súbory netplan a trvalé trasy Windows ju pri ďalšom pripojení alebo štarte nainštalujú znova, takže pred akoukoľvek úpravou nájdite súbor alebo profil, ktorý ju vlastní.

Potom skontrolujte IPv6 samostatne. ip -6 route a Get-NetRoute -AddressFamily IPv6 držia oddelený stav, oddelené predvolené trasy a oddelené správanie klienta. Audit iba IPv4 nič nehovorí o hoste s dvojitým zásobníkom, ktorý potichu uprednostňuje natívnu cestu IPv6, a to samo môže spôsobiť, že klient vyzerá ako split-tunnel.

Potvrďte vlastným tokom aplikácie

Zaznamenajte cieľ, ktorý aplikácia skutočne používa, a potom sa systému opýtajte na cestu, ktorú by si zvolil zo zdrojovej adresy, ku ktorej sa táto aplikácia viaže. ip route get 10.20.5.9 from 192.168.1.40 na to odpovedá v Linuxe; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus lokálna adresa to robí vo Windows. Porovnajte výsledok s tým, čo profil tvrdí. Stránka verejnej IP v prehliadači testuje jeden cieľ na jednom protokole a nič nehovorí o privátnej adrese, ktorá sťažnosť začala.

Opravte najužší objekt, ktorý rozdiel vysvetľuje. Ak je výnimka schválená, zapíšte prefix a nechajte ho; ak nie, odstráňte trasu alebo pridajte výslovnú užšiu trasu tunelom namiesto znižovania metriky predvolenej trasy. Zníženie metriky nemôže predbehnúť dlhší prefix a úprava predvolenej trasy, kým dve trasy /1 vlastnia internetovú cestu, tiež nič nemení.

Potom tunel znova pripojte a ten istý dotaz zopakujte. Klienti pri každom pripojení preinštalujú trasy, takže zmena, ktorá vydrží len do ďalšieho handshaku, nie je otestovaná. Ak sa cesta stále rozchádza, zostávajúcimi podozrivými sú pravidlo politiky, druhá tabuľka alebo filter na strane klienta — nie predvolená trasa.

• Pomenujte cieľ a zdrojovú adresu, ktoré aplikácia skutočne používa.
• Vypíšte víťaznú trasu pomocou ip route get alebo Find-NetRoute.
• Skontrolujte, či internetovú cestu vlastní pár /1 alebo tabuľka politiky.
• Uveďte každý prefix dlhší ako /0, ktorý zodpovedá cieľu.
• Zopakujte kontrolu IPv6 samostatne.
• Vystopujte zostávajúcu trasu späť k súboru, profilu alebo filtru, ktorý ju inštaluje.
• Znova sa pripojte a znova spustite dotaz, kým to označíte za opravené.

Ak všetkých sedem súhlasí s profilom, tunel robí presne to, na čo bol nakonfigurovaný, a oprava patrí do profilu, nie do metriky.