De ce regula ta de split tunnel a încetat să se potrivească cu un serviciu

Split tunneling eșuează de obicei într-unul din două feluri. Fie traficul care ar trebui să fie în tunel ocolește tunelul, fie traficul care ar trebui să rămână afară este tras înăuntru. Defecțiunea din regula învechită este primul tip, și este cea mai confuză, pentru că regula este aplicată exact cum a fost scrisă. Ce s-a schimbat este destinația: serviciul răspunde acum pe o adresă pe care regula nu a numit-o niciodată, iar în tunel nu este nimic greșit.

Ce fixează regula și ce returnează DNS

O regulă de split tunnel este o afirmație statică despre destinații, de obicei exprimată ca un prefix, o rută sau o listă de adrese. Este evaluată față de destinația pachetului în momentul trimiterii. Un nume de host este o interogare care returnează un set de adrese cu o durată de viață și un cache, iar răspunsul poate varia în funcție de resolver, de tipul interogării și de minut.

Cele două obiecte nu negociază niciodată între ele. Regula continuă să se potrivească cu prefixul primit, serviciul continuă să schimbe adresa pe care o emite, iar golul dintre ele se lărgește în tăcere. De aceea simptomul apare după o migrare a furnizorului sau o reînnoire a certificatului, nu după o schimbare de configurație. Nimeni nu a editat tunelul, deci nimeni nu se uită la tunel, iar diagnosticul alunecă spre aplicație în locul politicii.

Trei moduri în care se rupe potrivirea

Cazul evident este un serviciu mutat: operatorul i-a dat o adresă nouă, DNS a urmat, iar excepția nu. Al doilea este o familie de adrese pe care regula nu a acoperit-o niciodată, ceea ce se întâmplă când un nume începe să returneze înregistrări AAAA pe care o excepție doar pentru IPv4 le ignoră. Al treilea este o diferență de resolver: o vedere internă și una publică pot returna adrese diferite pentru același nume, deci adresa pe care o folosește aplicația ta nu este cea cu care ai testat.

O conexiune din cache este o a patra variantă și este ușor de ratat. Aplicația poate vorbi încă cu o adresă pe care a rezolvat-o acum o oră, ceea ce înseamnă că interogarea ta proaspătă și socketul ei deschis nu sunt de acord unde locuiește serviciul.

Citește destinația pe care aplicația o folosește cu adevărat

Întreabă sistemul de operare și tabelul de socketuri, nu o filă de browser. Interogarea răspunde la ce se rezolvă numele acum, iar tabelul de socketuri arată adresa la care este conectat procesul, care poate fi mai veche. Rulează ambele înainte de a formula o teorie, pentru că diferența dintre ele este ea însăși răspunsul în aproximativ jumătate din cazuri.

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

Apoi compară cu ceea ce acoperă regula. Dacă adresa actuală cade în afara excepției și cererea tot eșuează, ai găsit cauza fără să atingi configurația tunelului. Dacă aplicația este conectată la o adresă care corespunde regulii și cererea tot eșuează, problema este undeva dincolo de tunel și aceasta este investigația greșită.

Repară mecanismul, nu simptomul

Dacă produsul acceptă direcționare întreținută bazată pe domenii, folosește-o și urmează comportamentul documentat de reîmprospătare și de acoperire. Aceasta înlocuiește o presupunere statică cu un răspuns întreținut, cu prețul de a depinde de funcționarea caracteristicii conform documentației.

Dacă designul se bazează pe o listă statică, dă-i un proprietar și un plan de actualizare. Planul ar trebui să spună cum este descoperită adresa, cine aprobă schimbarea și cât de repede se așteaptă ca lista să urmeze o migrare a furnizorului. O listă fără proprietar este o viitoare cădere cu o cauză cunoscută.

Nu lărgi excepția la o mare rețea vecină doar ca să prinzi fiecare adresă văzută în timpul unui test scurt. Aceasta nu este o reparație; este o schimbare permanentă a graniței de securitate și va lăsa în tăcere servicii neînrudite să ocolească tunelul cât timp regula există.

Verifică ambele jumătăți ale intenției

Un design de split tunnel are două intenții, iar o reparație ar trebui să le păstreze pe amândouă. Serviciul protejat trebuie să treacă prin tunel, iar categoriile excluse trebuie să continue să îl ocolească. Testează o conexiune nouă la destinația reparată, apoi testează ceva care ar trebui să rămână afară.

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'

Notează noua adresă, mecanismul ales și data. Acea notă este cea care împiedică următoarea persoană să concluzioneze că VPN-ul și-a ignorat configurația proprie la întâmplare.