Je plné tunelovanie jednoduchšie než dlhý zoznam rozdeleného tunelovania?

Zoznam rozdeleného tunelovania začína tromi aplikáciami a nakoniec pokrýva väčšinu stroja, a každý nový riadok je niekoho výnimka. V tom bode sa zoznam potichu stal predvoleným nastavením s krokmi navyše. Plné tunelovanie obracia usporiadanie: všetko vstupuje do tunela, ak zdokumentované vylúčenie nehovorí inak. Či je to jednoduchšie, závisí od brány a od lokálnych služieb, ktoré by ste pokazili.

Začnite počítaním pravidiel, ktoré udržiavate

Spočítajte položky, potom spočítajte, koľko z nich má menovaného vlastníka a dátum posledného overenia. Dôležité je to druhé číslo, pretože výnimku bez vlastníka nemožno vyhodnotiť, keď sa softvér, na ktorý odkazuje, premenuje alebo nahradí. Pravidlá naviazané na cestu spustiteľného súboru po aktualizácii potichu zlyhajú, a zlyhanie vyzerá ako nestabilný VPN, nie ako zastarané pravidlo. Zapíšte zoznam, skôr než si o ňom urobíte názor.

Každá položka by mala odpovedať na tri otázky: čo sa bez nej pokazí, kto to rozhodol a ako by ste si všimli, že dôvod vypršal. Položky, ktoré nevedia odpovedať na všetky tri, sú kandidátmi na vymazanie, nie na migráciu, a ich skoršie vymazanie robí neskoršie porovnanie čestným.

Ak väčšina položiek smeruje veľký podiel prevádzky, už prevádzkujete plný tunel s pridruženou záťažou údržby. Rozhodnutie je potom o tom, kde predvolené nastavenie žije, nie o tom, či ho mať.

Skontrolujte, či brána unesie predvolené nastavenie

Plné tunelovanie presúva každý paket na jedno zariadenie, čo súčasne mení zaťaženie CPU, conntrack tabuľku, preklad adries a požiadavku na upstream šírku pásma tohto zariadenia. Brána, ktorá pohodlne obsluhovala niekoľko interných podsietí, nemusela byť dimenzovaná na celé prehliadanie jedného používateľa. Pozerajte sa na najväčší očakávaný počet súbežných relácií, nie na priemer, pretože vrchol sa zlomí prvý.

ip -s link show dev tun0
conntrack -C
ss -s

Zmerajte rovnakú záťaž pred zmenou a po nej namiesto uvažovania zo špecifikácií. Jedno popoludnie bežného používania na jednom stroji ukáže, či je brána blízko limitu, a nestojí to nič v porovnaní s odhalením v pondelok ráno.

Skontrolujte aj path MTU od konca do konca, pretože plné predvolené nastavenie vystavuje každú aplikáciu maximálnej veľkosti paketu tunela. Aplikácie, ktoré fungovali mimo tunela, môžu teraz závisieť od správania fragmentácie, o ktorom ste nikdy nemuseli uvažovať.

Potvrďte, že lokálne služby a súkromný DNS stále fungujú

Vymenujte, čo musí zostať lokálne podľa protokolu, nie podľa názvu aplikácie: protokoly objavovania pre tlačiarne a displeje, mostík smart domácnosti, administračná stránka smerovača, lokálny vývojový server dostupný pod menom, ktoré sa prekladá len v sieti LAN. To sa pokazí, keď predvolená trasa začne ukazovať do tunela, a pokazí sa potichu, pretože na klientovi nič nezaznamená chybu.

Súkromný DNS je druhá závislosť. Ak interné mená predtým prekladal resolver tunela, nič sa nemení; ak sa prekladali lokálne, plné predvolené nastavenie ich musí dostať k resolveru, ktorý pozná zóny. Otestujte jedno interné a jedno verejné meno po zmene namiesto toho, aby ste predpokladali, že zoznam resolverov prežil.

Zapíšte lokálne výnimky do profilu, ktorý ich vlastní. Výnimka uchovávaná iba v niekoho pamäti je prvá vec, ktorú nasledujúca migrácia stratí.

Migrujte jeden profil a overte hranice

Zmeňte profil cez jeho vlastnú konfiguráciu, namiesto vrstvenia nového predvoleného nastavenia na manuálne trasy, ktoré zostali po predchádzajúcich experimentoch. Tie zostávajúce trasy sú obvyklou príčinou migrácie, ktorá vyzerá, že funguje, a o deň neskôr sa správa nekonzistentne. Držte starý profil dostupný, aby návrat bol voľbou, nie prestavbou.

Potom overte dve hranice oddelene: že verejné aj súkromné destinácie fungujú, a že nechcená prevádzka neopúšťa tunel. Úspešné načítanie stránky dokazuje prvé a o druhom nehovorí nič.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Zopakujte kontrolu po opätovnom pripojení a po výpadku, pretože kill switch, ktorý počas výpadku blokuje prevádzku, je iná vlastnosť než trasa, ktorá sa potom správne obnoví. Jednoduchší návrh je ten, ktorého skutočné pokrytie ešte dokážete vysvetliť po zmene aplikácie alebo siete.