Proč vaše pravidlo split tunelování přestalo odpovídat službě

Split tunelování obvykle selhává jedním ze dvou způsobů. Buď provoz, který má být v tunelu, jde mimo něj, nebo se provoz, který má zůstat venku, táhne dovnitř. Selhání kvůli zastaralému pravidlu je první případ a je to ten matoucí, protože pravidlo se vyžaduje přesně tak, jak je napsané. Změnil se cíl: služba teď odpovídá na adrese, kterou pravidlo nikdy nejmenovalo, a na tunelu není nic špatně.

Co pravidlo fixuje a co vrací DNS

Pravidlo split tunelování je statické tvrzení o cílech, obvykle vyjádřené jako prefix, trasa nebo seznam adres. Vyhodnocuje se proti cíli paketu v okamžiku odeslání. Název hostitele je dotaz, který vrací sadu adres s životností a cache, a odpověď se může lišit podle resolveru, typu dotazu a minuty.

Tyto dva objekty spolu nikdy nevyjednávají. Pravidlo dál odpovídá prefixu, který dostalo, služba dál mění adresu, kterou vydává, a mezera mezi nimi se tiše zvětšuje. Proto se symptom objeví po migraci poskytovatele nebo obnově certifikátu, a ne po změně konfigurace. Nikdo tunel neupravoval, takže se na tunel nikdo nedívá, a diagnostika se posouvá k aplikaci místo k politice.

Tři způsoby, jak se shoda rozbije

Zřejmý případ je přestěhovaná služba: operátor jí dal novou adresu, DNS ho následoval a výjimka ne. Druhý je rodina adres, kterou pravidlo nikdy nepokrylo, což se stane, když název začne vracet záznamy AAAA, které výjimka pouze pro IPv4 ignoruje. Třetí je rozdíl resolveru: interní a veřejný pohled mohou pro stejný název vracet různé adresy, takže adresa, kterou vaše aplikace používá, není ta, se kterou jste testovali.

Uložené spojení je čtvrtá varianta a snadno se přehlédne. Aplikace může stále mluvit s adresou, kterou vyřešila před hodinou, což znamená, že váš čerstvý dotaz a její otevřený socket se neshodují v tom, kde služba sídlí.

Přečtěte si cíl, který aplikace skutečně používá

Ptejte se operačního systému a tabulky socketů, ne panelu prohlížeče. Dotaz odpovídá, na co název právě teď převádí, a tabulka socketů ukazuje adresu, ke které je proces připojen, a ta může být starší. Spusťte obojí, než si uděláte teorii, protože rozdíl mezi nimi je v přibližně polovině případů sám odpovědí.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Pak to porovnejte s tím, co pravidlo pokrývá. Pokud současná adresa spadá mimo výjimku a požadavek stále selhává, našli jste příčinu, aniž byste se dotkli konfigurace tunelu. Pokud je aplikace připojena k adrese, která pravidlu odpovídá, a požadavek stále selhává, problém je za tunelem a toto je špatné vyšetřování.

Opravte mechanismus, ne symptom

Pokud produkt podporuje udržované směrování podle domén, použijte ho a řiďte se jeho dokumentovaným chováním při obnově a rozsahu. Nahradí to statický odhad udržovanou odpovědí, za cenu závislosti na tom, že funkce funguje podle dokumentace.

Pokud se návrh opírá o statický seznam, dejte mu vlastníka a plán aktualizace. Plán by měl říkat, jak se adresa zjišťuje, kdo změnu schvaluje a jak rychle má seznam následovat migraci poskytovatele. Seznam bez vlastníka je budoucí výpadek se známou příčinou.

Nerozšiřujte výjimku na velkou sousední síť jen proto, abyste zachytili každou adresu, kterou jste viděli při krátkém testu. To není oprava; je to trvalá změna bezpečnostní hranice a potichu nechá nesouvisející služby obcházet tunel, dokud pravidlo existuje.

Ověřte obě poloviny záměru

Návrh split tunelování má dva záměry a oprava by měla zachovat oba. Chráněná služba musí jít tunelem a vyloučené kategorie musí dál obcházet kolem něj. Otestujte nové spojení na opravený cíl a pak otestujte něco, co má zůstat venku.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Zapište novou adresu, zvolený mechanismus a datum. Právě tahle poznámka zabrání dalšímu člověku, aby usoudil, že VPN náhodně ignorovala vlastní konfiguraci.