Split-tonnelering teen maatskappybeleid: watter reël wen
’n Korporatiewe ontwerp kan goedgekeurde uitgang, bestuurde DNS of eindpuntkontroles vereis. ’n Plaaslike omleiding weerspreek daardie ontwerp selfs wanneer dit een werf laat laai.
Om een program in ’n split-tonnel-kliënt te merk voel soos ’n plaaslike voorkeur, en op ’n bestuurde toestel is dit nader aan ’n beleidsverandering. Die uitsondering skuif verkeer weg van die goedgekeurde pad, wat dieselfde pad kan wees wat bestuurde DNS, filtering en die bronadres dra wat ’n diens herken. Die kliënt tree nie verkeerd op wanneer dit jou wysiging terugdraai nie; die ontplooiing doen sy werk.
Voordat jy oor die merkblokkie stry, bepaal watter eienskap die beleid bestaan om te beskerm.
Die eienskap agter die reël
Sommige ontplooiings lei alles sodat alle verkeer deur ’n goedgekeurde poort gaan. Ander gee om naamresolusie en hou navrae by die korporatiewe oplosser eerder as by dié van die plaaslike netwerk. Nog ander het ’n stabiele bronadres nodig sodat interne dienste kan besluit of hulle hoegenaamd moet antwoord.
’n Vierde groep dwing die toestand van die eindpunt af: skyfversleutelingsstatus, pleistervlak, agentgesondheid. Om die tonnel te verdeel verander dit nie, terwyl ’n omleiding wat die agent se eie verkeer vermy dit wel kan verander.
Dit is vier verskillende vereistes, en elkeen word deur ’n ander uitsondering gebreek. Lees die vereiste voordat jy die verandering voorstel, want die persoon wat dit geskryf het, kan jou dadelik sê watter een geld. ’n Verandering wat die verkeerde een bevredig, koop niks.
Twee bewerings is die moeite werd om vroeg te verwerp. Volle tonneling gee nie vir administrateurs elke gewone teksblad nie, want toepassingsversleuteling en eindpuntkontroles bepaal wat sigbaar is. Split-tonnelering is ook nie universeel onveilig nie, want bestuurde DNS, per-toepassing-beleide en eindpuntagente kan geld ongeag die roete.
Voer die kontroles in volgorde uit
Die volgorde hieronder verklein ’n uitsondering tot die kleinste ding wat werklik gefaal het. Stop by die eerste kontrole wat nie geld nie, want ’n latere regstelling kan nie ’n vroeëre gaping vergoed nie.
Vra watter verkeer nou die goedgekeurde poort mis, en bevestig dan dat naamresolusie steeds die korporatiewe oplosser bereik. Kyk of die betrokke toepassing ’n doodskakelaar respekteer, of of dit die mislukte poging op ’n direkte roete deurgebring het. Kyk dan na gedeelde dienste: ’n dokumentkyker of opdateringsmakelaar kan die uitsondering verder dra as wat die merkblokkie suggereer. Let laastens op of die beleid by heraansluiting weer toegepas word, want daardie gedrag besluit of enige plaaslike verandering oorleef.
Elke antwoord is ’n feit, en feite is wat ’n uitsonderingsversoek nodig het. ’n Argument oor of die VPN irriterend is, is nie een daarvan nie. Skryf die antwoorde neer voordat die gesprek begin.
Vra vir ’n smal uitsondering
Rapporteer die toepassing, die bestemming en die bewerking wat gefaal het, in daardie volgorde. ’n Versoek om een opdateringsprogram op die direkte pad te hou, is hersienbaar; ’n versoek om die tonnel vir die hele blaaier te omseil, is nie.
Beskryf wat jy reeds probeer het en wat die logboeke gewys het, en rig dit aan die span wat die profiel besit eerder as aan wie ook al die hulpbank antwoord. Op ’n bestuurde toestel kan die profieleienaar gewoonlik ’n ondersteunde uitsondering skep wat opdaterings oorleef, terwyl ’n plaaslike roetewysiging dit nie kan nie.
As die antwoord nee is, behandel dit as ’n ontwerpbesluit en nie as ’n hindernis om te omseil nie. Die volgende hersiening is die plek om dit weer oop te maak, met die mislukte bewerking gedokumenteer en die besigheidsrede aangeheg. Om dit te omseil waag meer as wat die uitsondering ooit werd was.
Maak die uitsondering oorleefbaar
Bevestig ná ’n goedgekeurde verandering die dele wat voorheen gewerk het, nie net die deel wat gebreek was nie. Interne name moet steeds deur die korporatiewe oplosser opgelos word, private hulpbronne moet steeds antwoord, en die taak wat voorheen gefaal het, moet nou voltooi.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
Die eerste opdrag bewys dat die oplosser steeds vir ’n interne agtervoegsel antwoord, en die tweede bewys dat ’n versoek die interne diens vanaf die huidige roete bereik. Voer hulle weer uit ná ’n heraansluiting, want ’n beleidsstoot kan stilweg ongedaan maak wat tydens die toets stabiel gelyk het. Twee reëls uitset wat by die kaartjie gestoor word, sluit die lus. Sonder hulle rus die uitsondering op iemand se herinnering aan ’n bladsy wat een keer gelaai het.
Teken die uitsondering, sy doel en die komponente wat dit dek op dieselfde plek as die ontplooiingsnotas aan. ’n Ongedokumenteerde uitsondering word volgende kwartaal se voorval, en ’n gedokumenteerde een word bewys dat die ontwerp ’n werklike werklading hanteer.