Ako rozlíšiť trasy vnútené VPN od statických v Linuxe

Prefix sa na notebooku objaví, keď sa tunel zdvihne, takže to vyzerá, že ho nainštaloval VPN. Možno áno, ale rovnaký výsledok môže prísť od klientskeho skriptu, ktorý sa spúšťa pri pripojení, od profilu pripojenia, ktorý uvádza podsiet, alebo od statickej trasy, ktorá tam bola celý čas a začala fungovať až vtedy, keď rozhranie existovalo. Výber nesprávneho vlastníka znamená, že sa trasa po každom čistení vráti a ďalší človek opakuje tú istú opravu. Nasledujúci postup tieto tri oddelí skôr, než sa čokoľvek zmení.

Krok 1: pomenujte mechanizmus, ktorý inštaluje prefixy

Rôzne protokoly zabezpečujú dostupnosť rôznymi spôsobmi a nazývať to všetko oznámením skrýva rozdiel. Server OpenVPN vnucuje direktívu trasy cez riadiaci kanál a klient ju nainštaluje, ak ju nezablokuje pull filter. Konfigurácia WireGuard uvádza povolené prefixy lokálne a klient ich používa tak na smerovanie kryptokľúčov, ako aj na trasy, ktoré pridáva. Tunel IPsec sa s protistranou dohodne na selektoroch prevádzky a jadro z týchto selektorov inštaluje trasy.

Skôr než začnete čítať akúkoľvek tabuľku, určte, ktorý z nich váš tunel používa. Trasa vnútená pri pripojení nie je oznámením smerovacieho protokolu a nesľubuje, že prefix je za vzdialeným koncom dostupný. Poznamenajte si mechanizmus vedľa prefixu, pretože rozhoduje o tom, kam oprava patrí.

Krok 2: porovnajte tabuľku naprieč pripojením

Uložte hlavnú tabuľku so spusteným tunelom dole, zdvihnite ho, uložte ju znova a porovnajte obe snímky. Všetko, čo sa objavilo, patrí k životnému cyklu pripojenia, a všetko, čo zostalo, patrí k miestnej konfigurácii.

Zachyťte ju pomocou ip route show table main > /tmp/route-down.txt, pripojte sa a zachyťte znova. To isté urobte pre ip -6 route, ak lokalita používa IPv6, pretože chýbajúci prefix tam vytvára poruchy, ktoré vyzerajú nesúvisiace so smerovaním.

Krok 3: čítajte metriku, nielen prítomnosť

Dva záznamy pre ten istý prefix môžu existovať vedľa seba a jadro vyberá nižšiu metriku. Statická trasa s metrikou 50 bude naďalej porážať vnútenú trasu so 100, aj keď sú obe viditeľné, a preto „trasa tam je“ a „prevádzka ju používa“ sú rozdielne tvrdenia.

Opýtajte sa jadra priamo pomocou ip route get 10.20.5.7 a prečítajte rozhranie, ktoré uvádza. Ak prevádzka odchádza cez fyzický adaptér, zatiaľ čo v tabuľke leží trasa tunela, vysvetľuje to metrika alebo dĺžka prefixu, nie klient VPN. Zopakujte dopyt pre hostiteľa, o ktorom viete, že je za tunelom, a pre toho, o ktorom viete, že nie je, a rozdiel ukáže, či sa rozdelenie správa podľa zámeru.

Krok 4: nájdite záznamy, ktoré tunel prežijú

Statické trasy prežívajú odpojenie podľa návrhu a odtiaľ pochádzajú zastarané záznamy. Trvalá trasa ukazujúca na rozhranie, ktoré už neexistuje, môže podsiet ticho pohltiť, a trasa na znovupoužité meno rozhrania môže po reštarte poslať súkromnú prevádzku nesprávnymi dverami.

Skontrolujte trvalú stranu na mieste, ktoré používa vaša distribúcia, či už je to jednotka systemd-networkd, profil NetworkManageru alebo skript v klientskom adresári up. Oprava živej tabuľky pomocou ip route del vydrží len do ďalšieho pripojenia. Berte to vymazanie ako test hypotézy, nie ako opravu.

Keď vzdialený koniec poskytuje nesprávne pokrytie, riešte to s operátorom, namiesto toho aby ste filtrovali všetko. Zahodenie všetkých vnútených nastavení zahadzuje aj DNS a politiku rozdeleného tunela, na ktorých profil závisí.

Krok 5: potvrďte spiatočnú cestu, skôr než obviníte klienta

Pri spojení lokalita-lokalita alebo podsieti za tunelom potrebuje vzdialená strana trasu späť na adresu vášho klienta a zapnuté preposielanie na bráne. Jednosmerná cesta vyzerá presne ako chyba smerovania na klientovi, len handshake aj odchádzajúci paket uspejú.

Filtrovanie spätnej cesty pridáva na linuxových bránach druhú pascu. Odpoveď, ktorá dorazí na iné rozhranie, než trasa predpovedá, je v prísnom režime zahodená, a asymetrické cesty cez dvoch poskytovateľov to spoľahlivo spúšťajú. Počítadlá zahodenia na bráne, nie na klientovi, povedia, či je príčinou filtrovanie.

Krok 6: testujte zdroj, nie ping

Keď je zvolená trasa správna, otvorte skutočný zdroj a potvrďte spiatočnú prevádzku. Odpoveď na ping dokazuje cestu jedným smerom a nič o službe, a služba odpovedajúca na kešované spojenie dokazuje ešte menej.

Potom celú kontrolu zopakujte po opätovnom pripojení. Hodnota postupu je v tom, že predpovedá, čo urobí ďalšie pripojenie, a preto do tiketu patrí porovnanie aj metrika.