Per-toepassing-VPN-uitsonderings breek wanneer ’n gedeelde diens data haal

Jy sluit een toepassing van die VPN uit en die aflaai wat dit nodig gehad het, misluk steeds, of erger, dit begin werk en iets anders hou op. Die sigbare venster is nie noodwendig die proses wat elke verbinding oopmaak nie: ’n toepassing kan werk aan ’n helper, ’n agtergrondoordragdiens of heeltemal ’n ander pakket oorhandig. ’n Per-toepassing-reël het dus die platform se werklike identiteitsmodel nodig, nie ’n bekende launcher-lêernaam nie. Die kontroles hieronder begin by die waarneming en werk terug na wie die versoek werklik gedoen het.

Twee dinge gaan gewoonlik saam verkeerd in hierdie kaartjies: die verkeerde komponent word uitgesluit, en die uitsondering word daarna nooit vernou nie.

Vind die proses, nie die venster nie

Reproduseer die mislukte bewerking en identifiseer die proses of pakket wat die verbinding besit terwyl dit gebeur. Op Windows is dit ’n ander vraag as watter venster fokus het, want ’n agtergrondoordrag kan deur ’n diens bemiddel word wat onder sy eie identiteit loop. Op Linux en macOS verskyn dieselfde splitsing as helperprosesse en stelseldaeons.

Skryf drie besonderhede neer: die uitvoerbare of pakket se identiteit, die bestemming waarmee dit verbind het, en die oomblik in die werkvloei toe dit gebeur het. ’n Aflaai wat aan die begin misluk, is dikwels ’n metadata-ophaling deur ’n ander komponent as ’n aflaai wat halfpad misluk. Daardie onderskeid alleen is gewoonlik genoeg om die regte identiteit te kies voordat jy aan die reël raak. As die identiteit blyk ’n diens te wees eerder as ’n toepassing, verander daardie enkele feit die hele reël, so stel dit eerste vas.

As jy die proses nie kan waarneem nie omdat die bewerking te kort is, herhaal dit met ’n groter vrag of ’n stadiger bestemming. Die doel is een herhaalbare waarneming, nie ’n teorie oor watter helper betrokke is nie.

Hanteer DNS as sy eie pad

Stelselnaamoplossing volg dalk glad nie die uitgeslote toepassing nie, en daarom kan ’n uitgeslote blaaier steeds op ’n private gasheernaam misluk terwyl sy verkeer korrek buite die tonnel is. Die blaaier is uitgesluit; die oplosser nie.

Kyk wat die platform met DNS doen wanneer ’n per-toepassing-reël geld, en kyk daarna afsonderlik van die HTTP-versoek. As die oplosser ’n gedeelde diens is, bedien dit elke toepassing op die toestel, so die uitsondering wat jy oorweeg, het ’n veel wyer gehoor as die een wat jy getoets het.

Teken aan watter oplosser geantwoord het en deur watter koppelvlak. Daardie enkele waarneming los ’n groot deel van die verslae op oor “die toepassing is uitgesluit, maar die naam los nie op nie”, so hou dit by die kaartjie.

Moet nie ’n gedeelde helper verbreed nie

’n Gedeelde diens verrig werk vir verskeie toepassings, so om dit uit te sluit om een werkvloei te herstel, verander ook onverwante verkeer. Die Background Intelligent Transfer Service op Windows is ’n goeie voorbeeld van die vorm: dit is infrastruktuur wat baie toepassings kan gebruik, en sy identiteit is nie die identiteit van die toepassing wat die oordrag aangevra het nie.

Kontroleer die kliënt se ondersteunde reëlmodel en die organisasie se vereistes voordat jy daardie uitsondering byvoeg. Vra wat anders die komponent gebruik, en of die reël wat jy op die punt is om te skryf teen bestemmings uitgedruk kan word eerder as teen ’n gedeelde proses.

As die vereiste glad nie as ’n toepassingsgrens uitgedruk kan word nie, is ’n bestemmingsgebaseerde beleid of ’n ander goedgekeurde ontwerp dalk meer verstaanbaar en veiliger as ’n groeiende lys helper-uitsonderings.

Toets die hele werkvloei, nie die mislukte stap nie

Voer die beoogde taak ná ’n ondersteunde verandering van begin tot einde uit met ’n nuwe versoek. Voer dan een ander werkvloei uit wat die gedeelde komponent gebruik, want dit is waar ’n breë omleiding homself aankondig. ’n Regstelling wat die eerste herstel en die tweede stilweg breek, is nie ’n regstelling nie. Hou albei resultate in die kaartjie en noem die tweede werkvloei uitdruklik, sodat ’n keurder dit kan herhaal.

Hou die toets klein en herhaalbaar: dieselfde bestemming, dieselfde rekening, dieselfde toestande. As die tweede werkvloei nie gedokumenteer is nie, vra sy eienaar waarvan dit afhang voordat jy besluit die verandering is veilig.

Los ’n rede, nie ’n lys name nie

Dokumenteer die komponent, die werkvloei wat dit bedien en die rede waarom dit uitgesluit is. ’n Lys helpername sonder enige doel word binne twee vrystellingsiklusse ononderhoubaar, en die volgende ingenieur verwyder die verkeerde inskrywing terwyl hy dit opruim.

Een reël per uitsondering is genoeg: wat breek sonder dit, wie besit daardie werkvloei, en wanneer dit laas geverifieer is. Daardie drie velde verander ’n raaisellys in ’n beleid wat iemand kan verdedig.