Miért nem egyezik már a split-tunnel szabály egy szolgáltatással

A split tunneling általában kétféleképpen hibázik. Vagy az alagúton belülre tartozó forgalom megkerüli, vagy a kívül maradó forgalom bekerül. Az elavult szabály hibája az első fajta, és ez a zavaróbb, mert a szabály pontosan úgy érvényesül, ahogy megírták. Ami megváltozott, az a cél: a szolgáltatás most olyan címen válaszol, amelyet a szabály sosem nevezett meg, és az alagútban semmi sem rossz.

Mit rögzít a szabály, és mit ad vissza a DNS

A split-tunnel szabály statikus állítás a célokról, rendszerint előtagként, útvonalként vagy címlistaként kifejezve. Küldéskor a csomag céljához mérődik. A hosztnév egy lekérdezés, amely élettartammal és gyorsítótárral rendelkező címhalmazt ad vissza, és a válasz eltérhet resolver, lekérdezéstípus és perc szerint.

Ez a két objektum soha nem tárgyal egymással. A szabály továbbra is a kapott előtaghoz illeszkedik, a szolgáltatás továbbra is változtatja a kibocsátott címet, és a köztük lévő rés csendesen szélesedik. Ezért jelenik meg a tünet szolgáltatóváltás vagy tanúsítvány-megújítás után, nem konfigurációváltozás után. Senki nem szerkesztette az alagutat, így senki nem néz az alagútra, és a diagnózis az alkalmazás felé sodródik a szabályzat helyett.

Három módja annak, ahogy az egyezés eltörik

A nyilvánvaló eset az elköltözött szolgáltatás: az üzemeltető új címet adott neki, a DNS követte, a kivétel nem. A második egy olyan címcsalád, amelyet a szabály sosem fedett le, ami akkor történik, amikor egy név elkezd olyan AAAA rekordokat visszaadni, amelyeket a csak IPv4-re szóló kivétel figyelmen kívül hagy. A harmadik a resolver különbsége: egy belső és egy nyilvános nézet ugyanarra a névre eltérő címeket adhat vissza, így az alkalmazása által használt cím nem az, amellyel tesztelt.

A gyorsítótárazott kapcsolat negyedik változat, és könnyű kihagyni. Az alkalmazás még mindig egy olyan címmel beszélhet, amelyet egy órával korábban oldott fel, ami azt jelenti, hogy a friss lekérdezése és a nyitott socket nem ért egyet abban, hol él a szolgáltatás.

Olvassa el a célt, amelyet az alkalmazás valóban használ

Kérdezze az operációs rendszert és a socket táblát, ne a böngészőlapot. A lekérdezés megválaszolja, hogy a név most mire oldódik fel, a socket tábla pedig azt a címet mutatja, amelyhez a folyamat kapcsolódik, és ez régebbi lehet. Futtassa mindkettőt, mielőtt elméletet alkot, mert a köztük lévő különbség az esetek nagyjából felében maga a válasz.

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

Ezután hasonlítsa össze azzal, amit a szabály lefed. Ha az aktuális cím kívül esik a kivételen, és a kérés továbbra is meghiúsul, megtalálta az okot anélkül, hogy hozzányúlt volna az alagút konfigurációjához. Ha az alkalmazás egy a szabálynak megfelelő címhez kapcsolódik, és a kérés továbbra is meghiúsul, a probléma az alagúton túl van, és ez a rossz vizsgálat.

A mechanizmust javítsa, ne a tünetet

Ha a termék támogat karbantartott, domainalapú irányítást, használja azt, és kövesse a dokumentált frissítési és hatókör-viselkedését. Ez egy statikus találgatást karbantartott válaszra cserél, azon az áron, hogy a funkciónak a dokumentált módon kell működnie.

Ha a tervezés statikus listára támaszkodik, adjon neki gazdát és frissítési tervet. A tervnek meg kell mondania, hogyan derül ki a cím, ki hagyja jóvá a változtatást, és milyen gyorsan várható, hogy a lista követi a szolgáltatóváltást. A gazda nélküli lista ismert okú jövőbeli kiesés.

Ne szélesítse a kivételt egy nagy szomszédos hálózatra csak azért, hogy elkapjon minden címet, amelyet egy rövid teszt során látott. Ez nem javítás; ez a biztonsági határ állandó megváltoztatása, és csendesen engedi, hogy a nem kapcsolódó szolgáltatások megkerüljék az alagutat, ameddig a szabály létezik.

Ellenőrizze a szándék mindkét felét

A split-tunnel tervezésnek két szándéka van, és a javításnak mindkettőt meg kell őriznie. A védett szolgáltatásnak az alagúton keresztül kell mennie, a kizárt kategóriáknak pedig továbbra is meg kell kerülniük. Teszteljen friss kapcsolatot a javított célhoz, majd teszteljen valamit, aminek kívül kell maradnia.

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'

Jegyezze fel az új címet, a választott mechanizmust és a dátumot. Ez a feljegyzés az, ami megakadályozza, hogy a következő ember arra a következtetésre jusson, hogy a VPN véletlenszerűen figyelmen kívül hagyta a saját konfigurációját.