Prečo vaše pravidlo split tunelovania prestalo zodpovedať službe

Split tunelovanie zvyčajne zlyháva jedným z dvoch spôsobov. Buď prevádzka, ktorá má byť v tuneli, ide okolo neho, alebo prevádzka, ktorá má zostať vonku, sa ťahá dnu. Zlyhanie pre zastarané pravidlo je prvý prípad a je to ten mätúcejší, pretože pravidlo sa presadzuje presne tak, ako je napísané. Zmenil sa cieľ: služba teraz odpovedá na adrese, ktorú pravidlo nikdy nemenovalo, a v tuneli nie je nič zlé.

Čo pravidlo fixuje a čo DNS vracia

Pravidlo split tunelovania je statické tvrdenie o cieľoch, zvyčajne vyjadrené ako prefix, trasa alebo zoznam adries. Vyhodnocuje sa proti cieľu paketu v čase odoslania. Názov hostiteľa je dopyt, ktorý vracia množinu adries s životnosťou a cache, a odpoveď sa môže líšiť podľa resolvera, typu dopytu a minúty.

Tieto dva objekty nikdy nevyjednávajú jeden s druhým. Pravidlo ďalej zodpovedá prefixu, ktorý dostalo, služba ďalej mení adresu, ktorú vydáva, a medzera medzi nimi sa ticho zväčšuje. Preto sa príznak objaví po migrácii poskytovateľa alebo obnovení certifikátu a nie po zmene konfigurácie. Nikto tunel neupravoval, takže nikto sa na tunel nepozerá, a diagnostika sa posúva k aplikácii namiesto k politike.

Tri spôsoby, ako sa zhoda rozbije

Zrejmý prípad je presťahovaná služba: operátor jej dal novú adresu, DNS ju nasledoval a výnimka nie. Druhý je rodina adries, ktorú pravidlo nikdy nepokrylo, čo sa stane, keď názov začne vracať záznamy AAAA, ktoré výnimka iba pre IPv4 ignoruje. Tretí je rozdiel resolvera: interný a verejný pohľad môže pre rovnaký názov vracať rôzne adresy, takže adresa, ktorú vaša aplikácia používa, nie je tá, s ktorou ste testovali.

Uložené spojenie je štvrtý variant a ľahko sa prehliadne. Aplikácia môže stále hovoriť s adresou, ktorú vyriešila pred hodinou, čo znamená, že váš čerstvý dopyt a jej otvorený socket sa nezhodujú v tom, kde služba sídli.

Prečítajte si cieľ, ktorý aplikácia naozaj používa

Spýtajte sa operačného systému a tabuľky socketov, nie karty prehliadača. Dopyt odpovedá, na čo sa názov práve teraz prevádza, a tabuľka socketov ukazuje adresu, ku ktorej je proces pripojený, a tá môže byť staršia. Spustite oboje, kým si vytvoríte teóriu, pretože rozdiel medzi nimi je v približne polovici prípadov sám odpoveďou.

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

Potom to porovnajte s tým, čo pravidlo pokrýva. Ak aktuálna adresa spadá mimo výnimky a požiadavka stále zlyháva, našli ste príčinu bez toho, aby ste sa dotkli konfigurácie tunela. Ak je aplikácia pripojená k adrese, ktorá pravidlu zodpovedá, a požiadavka stále zlyháva, problém je za tunelom a toto je nesprávne vyšetrovanie.

Opravte mechanizmus, nie príznak

Ak produkt podporuje udržiavané smerovanie podľa domén, použite ho a riaďte sa jeho dokumentovaným správaním pri obnove a rozsahu. Nahradí to statický odhad udržiavanou odpoveďou, za cenu závislosti od toho, že funkcia funguje podľa dokumentácie.

Ak sa návrh opiera o statický zoznam, dajte mu vlastníka a plán aktualizácie. Plán by mal povedať, ako sa adresa zisťuje, kto zmenu schvaľuje a ako rýchlo má zoznam nasledovať migráciu poskytovateľa. Zoznam bez vlastníka je budúci výpadok so známou príčinou.

Nerozširujte výnimku na veľkú susednú sieť len preto, aby ste zachytili každú adresu, ktorú ste videli pri krátkom teste. To nie je oprava; je to trvalá zmena bezpečnostnej hranice a potichu nechá nesúvisiace služby obchádzať tunel, kým pravidlo existuje.

Overte obe polovice zámeru

Návrh split tunelovania má dva zámery a oprava by mala zachovať oba. Chránená služba musí ísť tunelom a vylúčené kategórie musia naďalej obchádzať okolo neho. Otestujte nové spojenie na opravený cieľ a potom otestujte niečo, čo má zostať vonku.

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'

Zapíšte novú adresu, zvolený mechanizmus a dátum. Práve tá poznámka zabráni ďalšiemu človeku, aby usúdil, že VPN náhodne ignorovala vlastnú konfiguráciu.