Tunel divizat versus politica companiei: care regulă câștigă

Bifarea unei aplicații într-un client cu tunel divizat pare o preferință locală, iar pe un dispozitiv gestionat este mai aproape de o schimbare de politică. Excepția mută traficul de pe calea aprobată, care poate fi aceeași cale pe care merg DNS-ul gestionat, filtrarea și adresa sursă pe care un serviciu o recunoaște. Clientul nu se comportă greșit când anulează modificarea ta; implementarea își face treaba.

Înainte să te cerți pe caseta de bifare, află ce proprietate există politica să protejeze.

Proprietatea din spatele regulii

Unele implementări rutează totul astfel încât tot traficul să treacă printr-un gateway aprobat. Altele țin la rezolvarea numelor și păstrează interogările pe resolverul companiei, nu pe cel al rețelei locale. Altele au nevoie de o adresă sursă stabilă ca serviciile interne să poată decide dacă răspund.

Un al patrulea grup impune postura punctului final: starea criptării discului, nivelul de patch-uri, sănătatea agentului. Împărțirea tunelului nu schimbă asta, în timp ce o ocolire care evită traficul agentului însuși poate.

Sunt patru cerințe diferite și fiecare este încălcată de o excepție diferită. Citește cerința înainte de a propune schimbarea, pentru că autorul ei îți poate spune imediat care se aplică. O schimbare care o satisface pe cea greșită nu cumpără nimic.

Două afirmații merită respinse devreme. Tunelul complet nu le dă administratorilor fiecare pagină în text clar, pentru că criptarea aplicațiilor și controalele punctelor finale decid ce este vizibil. Nici tunelul divizat nu este universal nesigur, pentru că DNS-ul gestionat, politicile pe aplicație și agenții punctelor finale pot fi valabile indiferent de rută.

Rulează verificările în ordine

Secvența de mai jos restrânge o excepție la cel mai mic lucru care a eșuat cu adevărat. Oprește-te la prima verificare care nu se susține, pentru că o corectare ulterioară nu compensează o lipsă anterioară.

Întreabă ce trafic ratează acum gateway-ul aprobat, apoi confirmă că rezolvarea numelor ajunge încă la resolverul companiei. Verifică dacă aplicația respectivă respectă un întrerupător de urgență sau dacă a petrecut încercarea eșuată pe o rută directă. Apoi uită-te la serviciile partajate: un vizualizator de documente sau un broker de actualizări poate duce excepția mai departe decât sugerează caseta. În final notează dacă politica se reaplică la reconectare, pentru că acel comportament decide dacă vreo modificare locală supraviețuiește.

Fiecare răspuns este un fapt, iar o cerere de excepție are nevoie de fapte. O discuție despre cât de enervant este VPN-ul nu este unul dintre ele. Scrie răspunsurile înainte de a începe conversația.

Cere o excepție îngustă

Raportează aplicația, destinația și operația care a eșuat, în această ordine. O cerere de a păstra un actualizator pe calea directă poate fi analizată; o cerere de a ocoli tunelul pentru întregul browser nu.

Descrie ce ai încercat deja și ce au arătat jurnalele, și adreseaz-o echipei care deține profilul, nu celui care răspunde la asistență. Pe un dispozitiv gestionat, proprietarul profilului poate de obicei crea o excludere suportată care supraviețuiește actualizărilor, în timp ce o editare locală a rutei nu poate.

Dacă răspunsul este nu, tratează-l ca o decizie de design și nu ca un obstacol de ocolit. Următoarea revizuire este locul să o redeschizi, cu operația eșuată documentată și motivul de afaceri anexat. Ocolirea riscă mai mult decât a valorat vreodată excepția.

Fă excepția viabilă

După o modificare aprobată, confirmă părțile care funcționau înainte, nu doar partea care era stricată. Numele interne ar trebui să se rezolve în continuare prin resolverul companiei, resursele private să răspundă, iar sarcina care eșuase înainte să se finalizeze acum.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

Prima comandă dovedește că resolverul răspunde încă pentru un sufix intern, iar a doua că o cerere ajunge la serviciul intern de pe ruta curentă. Rulează-le din nou după reconectare, pentru că o împingere de politică poate anula în tăcere o modificare care părea stabilă în timpul testului. Două linii de ieșire salvate cu tichetul închid bucla. Fără ele, excepția se sprijină pe memoria cuiva despre o pagină care s-a încărcat o dată.

Consemnează excepția, scopul ei și componentele pe care le acoperă în același loc cu notele de implementare. O excepție nedocumentată devine incidentul trimestrului următor, iar una documentată devine dovada că designul suportă o sarcină reală de lucru.