Je plné tunelování jednodušší než dlouhý seznam rozděleného tunelu?

Seznam rozděleného tunelu začíná u tří aplikací a skončí tím, že pokrývá většinu stroje, a každý nový řádek je něčí výjimka. V tu chvíli se seznam tiše stal výchozím nastavením s kroky navíc. Plné tunelování obrací uspořádání: do tunelu jde všechno, pokud dokumentovaná výjimka neříká jinak. Zda je to jednodušší, závisí na bráně a na místních službách, které byste rozbili.

Začněte počítáním pravidel, která udržujete

Spočítejte položky a pak spočítejte, kolik z nich má jmenovaného vlastníka a datum posledního ověření. Důležité je druhé číslo, protože výjimku, kterou nikdo nevlastní, nelze vyhodnotit, když se software, na který odkazuje, přejmenuje nebo nahradí. Pravidla vázaná na cestu ke spustitelnému souboru po aktualizaci tiše přestanou fungovat, a selhání vypadá jako nestabilní VPN, ne jako zastaralé pravidlo. Napište seznam dřív, než si na něj uděláte názor.

Každá položka by měla odpovědět na tři otázky: co se bez ní rozbije, kdo to rozhodl a jak byste poznali, že důvod pominul. Položky, které neumějí odpovědět na všechny tři, jsou kandidáty na smazání, ne na migraci, a jejich první smazání udělá pozdější srovnání poctivým.

Pokud většina položek směruje velký podíl provozu, už provozujete plný tunel s navíc přiloženou zátěží údržby. Rozhodnutí je pak o tom, kde výchozí nastavení žije, ne o tom, zda ho mít.

Zkontrolujte, zda brána unese výchozí nastavení

Plné tunelování přesouvá každý paket na jedno zařízení, což současně mění jeho zatížení procesoru, tabulku conntrack, překlad adres a požadavek na odchozí šířku pásma. Brána, která pohodlně obsluhovala několik vnitřních podsítí, nemusela být dimenzovaná na celé uživatelovo prohlížení. Dívejte se na největší očekávaný počet souběžných relací, ne na průměr, protože první se zlomí špička.

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

Změřte stejnou zátěž před změnou a po ní, místo abyste uvažovali ze specifikací. Jedno odpoledne běžného používání na jednom stroji ukáže, zda je brána blízko limitu, a nestojí to nic ve srovnání s odhalením v pondělí ráno.

Zkontrolujte také MTU cesty od konce ke konci, protože plné výchozí nastavení vystavuje každou aplikaci maximální velikosti paketu tunelu. Aplikace, které fungovaly mimo tunel, teď mohou záviset na chování fragmentace, o kterém jste nikdy nemuseli uvažovat.

Potvrďte, že místní služby a privátní DNS stále fungují

Vyjmenujte, co musí zůstat lokální podle protokolu, ne podle názvu aplikace: objevovací protokoly pro tiskárny a displeje, můstek chytré domácnosti, stránka správy routeru, místní vývojový server dostupný pod jménem, které se překládá jen v LAN. To se rozbije, když výchozí trasa začne ukazovat do tunelu, a rozbije se to tiše, protože na klientu nic nezaznamená chybu.

Privátní DNS je druhá závislost. Pokud se vnitřní jména dřív překládala přes resolver tunelu, nic se nemění; pokud se překládala lokálně, plné výchozí nastavení je musí donést k resolveru, který zná zóny. Po změně otestujte jedno vnitřní a jedno veřejné jméno, místo abyste předpokládali, že seznam resolverů přežil.

Zapište místní výjimky do profilu, kterému patří. Výjimka uchovávaná jen v něčí paměti je první věc, kterou další migrace ztratí.

Migrujte jeden profil a ověřte hranice

Změňte profil jeho vlastní konfigurací, místo abyste vrstvili nové výchozí nastavení na ruční trasy zanechané dřívějšími experimenty. Tyto zbytkové trasy jsou obvyklou příčinou migrace, která vypadá funkčně a o den později se chová nekonzistentně. Udržujte starý profil dostupný, aby návrat byl volbou, ne přestavbou.

Pak ověřte dvě hranice odděleně: že veřejné i soukromé cíle fungují oba, a že nežádoucí provoz nevychází mimo tunel. Úspěšné načtení stránky dokazuje první a o druhém neříká nic.

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

Kontrolu zopakujte po opětovném připojení a po výpadku, protože přepínač, který při výpadku blokuje provoz, je jiná vlastnost než trasa, která se potom správně obnoví. Jednodušší návrh je ten, jehož skutečné pokrytí ještě dokážete vysvětlit poté, co se změní aplikace nebo síť.