Túnels dividits contra la política de l’empresa: quina regla guanya
Un disseny corporatiu pot exigir una sortida aprovada, DNS gestionat o comprovacions de punts finals. Un bypass local contradiu aquest disseny encara que faci carregar un sol lloc.
Marcar una aplicació en un client de túnel dividit sembla una preferència local, i en un dispositiu gestionat és més aviat un canvi de política. L’excepció desvia el trànsit del camí aprovat, que pot ser el mateix camí que porta el DNS gestionat, el filtratge i l’adreça d’origen que reconeix un servei. El client no es comporta malament quan revertix la vostra edició; el desplegament fa la seva feina.
Abans de discutir sobre la casella, esbrineu quina propietat existeix per protegir la política.
La propietat darrere de la regla
Alguns desplegaments ho encaminen tot perquè tot el trànsit passi per una passarel·la aprovada. A d’altres els importa la resolució de noms i mantenen les consultes al resolutor corporatiu en lloc del de la xarxa local. Uns tercers necessiten una adreça d’origen estable perquè els serveis interns puguin decidir si responen o no.
Un quart grup imposa la postura del punt final: estat del xifratge del disc, nivell de pedaços, salut de l’agent. Dividir el túnel no ho canvia, mentre que un bypass que evita el trànsit propi de l’agent sí que pot.
Són quatre requisits diferents, i cada un es trenca per una excepció diferent. Llegiu el requisit abans de proposar el canvi, perquè qui el va escriure us pot dir de seguida quin s’aplica. Un canvi que satisfà el requisit equivocat no compra res.
Dues afirmacions val la pena descartar-les aviat. El túnel complet no dona als administradors totes les pàgines en text pla, perquè el xifratge d’aplicacions i els controls de punt final decideixen què és visible. El túnel dividit tampoc no és universalment insegur, perquè el DNS gestionat, les polítiques per aplicació i els agents de punt final poden mantenir-se independentment de la ruta.
Executeu les comprovacions en ordre
La seqüència següent redueix una excepció a la cosa més petita que realment ha fallat. Atureu-vos a la primera comprovació que no es compleixi, perquè una correcció posterior no pot compensar una mancança anterior.
Pregunteu quin trànsit perd ara la passarel·la aprovada i després confirmeu que la resolució de noms encara arriba al resolutor corporatiu. Comproveu si l’aplicació en qüestió respecta un interruptor d’emergència o si ha gastat l’intent fallit en una ruta directa. Mireu després els serveis compartits: un visor de documents o un broker d’actualitzacions pot portar l’excepció més enllà del que suggereix la casella. Finalment, anoteu si la política es torna a aplicar en reconnectar, perquè aquest comportament decideix si qualsevol canvi local sobreviu.
Cada resposta és un fet, i els fets són el que necessita una sol·licitud d’excepció. Una discussió sobre si la VPN és empipadora no n’és un. Escriviu les respostes abans que comenci la conversa.
Demaneu una excepció estreta
Informeu de l’aplicació, la destinació i l’operació que ha fallat, en aquest ordre. Una sol·licitud per mantenir un actualitzador al camí directe és revisable; una sol·licitud per saltar-se el túnel per a tot el navegador no ho és.
Descriviu què heu provat ja i què han mostrat els registres, i adreceu-ho a l’equip que posseeix el perfil en lloc de a qui respon a l’ajuda. En un dispositiu gestionat, el propietari del perfil normalment pot crear una exclusió suportada que sobreviu a les actualitzacions, mentre que una edició local de la ruta no pot.
Si la resposta és no, tracteu-ho com una decisió de disseny i no com un obstacle a esquivar. La propera revisió és el lloc per reobrir-ho, amb l’operació fallida documentada i la raó de negoci adjunta. Esquivar-ho arrisca més del que l’excepció ha valgut mai.
Feu l’excepció viable
Després d’un canvi aprovat, confirmeu les parts que funcionaven abans, no només la part que estava trencada. Els noms interns haurien de resoldre’s encara a través del resolutor corporatiu, els recursos privats haurien de respondre i la tasca que abans fallava ara hauria de completar-se.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
La primera ordre demostra que el resolutor encara respon per a un sufix intern, i la segona demostra que una sol·licitud arriba al servei intern des de la ruta actual. Torneu-les a executar després de reconnectar, perquè un enviament de política pot desfer en silenci un canvi que semblava estable durant la prova. Dues línies de sortida desades amb el tiquet tanquen el cercle. Sense elles, l’excepció descansa en la memòria d’algú sobre una pàgina que es va carregar una vegada.
Registreu l’excepció, el seu propòsit i els components que cobreix al mateix lloc que les notes de desplegament. Una excepció no documentada es converteix en l’incident del proper trimestre, i una de documentada es converteix en prova que el disseny suporta una càrrega de treball real.