Përjashtimet e VPN-së për çdo aplikacion prishen kur një shërbim i përbashkët merr të dhënat

Ju përjashtoni një aplikacion nga VPN dhe shkarkimi që i nevojitej vazhdon të dështojë ose, më keq, fillon të funksionojë dhe diçka e palidhur ndalon. Dritarja e dukshme nuk është domosdoshmërisht procesi që hap çdo lidhje: një aplikacion mund t'ia dorëzojë punën një ndihmësi, një shërbimi transferimi në sfond ose një pakete krejt tjetër. Prandaj një rregull për çdo aplikacion kërkon modelin e vërtetë të identitetit të platformës, jo një emër të njohur skedari nisjeje. Kontrollet më poshtë nisin nga vëzhgimi dhe kthehen te kush e dërgoi vërtet kërkesën.

Në këto tiketa zakonisht dy gjëra prishen së bashku: përjashtohet komponenti i gabuar dhe përjashtimi nuk ngushtohet kurrë më pas.

Gjeni procesin, jo dritaren

Riprodhoni veprimin e dështuar dhe identifikoni procesin ose paketën që zotëron lidhjen ndërsa ajo ndodh. Në Windows kjo është një pyetje tjetër nga ajo se cila dritare ka fokusin, sepse një transferim në sfond mund të ndërmjetësohet nga një shërbim që punon nën identitetin e vet. Në Linux dhe macOS e njëjta ndarje shfaqet si procese ndihmëse dhe daemonë të sistemit.

Shkruani tre detaje: identitetin e skedarit ekzekutues ose të paketës, destinacionin me të cilin komunikonte dhe momentin në rrjedhën e punës kur ndodhi. Një shkarkim që dështon në fillim është shpesh marrje metadatash nga një komponent tjetër sesa një shkarkim që dështon në mes. Vetëm ky dallim zakonisht mjafton për të zgjedhur identitetin e duhur përpara se të prekni rregullin. Nëse identiteti rezulton të jetë shërbim dhe jo aplikacion, ky fakt i vetëm ndryshon të gjithë rregullin, prandaj përcaktoni fillimisht atë.

Nëse nuk mund ta vëzhgoni procesin sepse veprimi është shumë i shkurtër, përsëriteni me një ngarkesë më të madhe ose një destinacion më të ngadaltë. Qëllimi është një vëzhgim i riprodhueshëm, jo një teori se cili ndihmës është i përfshirë.

Trajtojeni DNS-në si rrugën e vet

Zgjidhja e emrave të sistemit mund të mos e ndjekë fare aplikacionin e përjashtuar, prandaj një shfletues i përjashtuar mund të dështojë ende në një emër pritësi privat ndërsa trafiku i tij është saktësisht jashtë tunelit. Shfletuesi ishte i përjashtuar; zgjidhësi jo.

Kontrolloni çfarë bën platforma me DNS kur zbatohet një rregull për çdo aplikacion dhe kontrollojeni veçmas nga kërkesa HTTP. Nëse zgjidhësi është një shërbim i përbashkët, ai u shërben të gjitha aplikacioneve në pajisje, prandaj përjashtimi që po shqyrtoni ka një audiencë shumë më të gjerë sesa ai që testuat.

Regjistroni cili zgjidhës u përgjigj dhe përmes cilit ndërfaqe. Ai vëzhgim i vetëm zgjidh një pjesë të madhe të raporteve «aplikacioni është i përjashtuar por emri nuk zgjidhet», prandaj mbajeni me tiketën.

Mos e zgjeroni një ndihmës të përbashkët

Një shërbim i përbashkët kryen punë për disa aplikacione, prandaj përjashtimi i tij për të rregulluar një rrjedhë pune ndryshon edhe trafikun e palidhur. Background Intelligent Transfer Service në Windows është një shembull i mirë i kësaj forme: është infrastrukturë që shumë aplikacione mund të përdorin, dhe identiteti i tij nuk është identiteti i aplikacionit që kërkoi transferimin.

Kontrolloni modelin e rregullave që mbështet klienti dhe kërkesat e organizatës përpara se të shtoni atë përjashtim. Pyetni se çfarë tjetër përdor komponentin dhe nëse rregulli që po shkruani mund të shprehet ndaj destinacioneve në vend të një procesi të përbashkët.

Nëse kërkesa nuk mund të shprehet fare si kufi aplikacioni, një politikë e bazuar në destinacione ose një dizajn tjetër i miratuar mund të jenë më të kuptueshëm dhe më të sigurt sesa një listë në rritje e përjashtimeve për ndihmësit.

Testoni të gjithë rrjedhën e punës, jo hapin që dështon

Pas një ndryshimi të mbështetur, ekzekutoni detyrën e synuar me një kërkesë të re nga fillimi në fund. Pastaj ekzekutoni një rrjedhë tjetër pune që përdor komponentin e përbashkët, sepse aty një anashkalim i gjerë e shpall veten. Një rregullim që rregullon të parën dhe prish në heshtje të dytën nuk është rregullim. Mbajini të dyja rezultatet në tiketë dhe emërtoni shprehimisht rrjedhën e dytë, që një rishikues ta përsërisë.

Mbani testin të vogël dhe të përsëritshëm: i njëjti destinacion, i njëjti llogari, të njëjtat kushte. Nëse rrjedha e dytë nuk është e dokumentuar, pyesni pronarin e saj nga se varet përpara se të vendosni që ndryshimi është i sigurt.

Lini një arsye, jo një listë emrash

Dokumentoni komponentin, rrjedhën e punës që shërben dhe arsyen pse u përjashtua. Një listë emrash ndihmësish pa qëllim të lidhur bëhet e pamenaxhueshme brenda dy cikleve të lëshimit, dhe inxhinieri i radhës heq zërin e gabuar ndërsa e pastron.

Një rresht për çdo përjashtim mjafton: çfarë prishet pa të, kush e zotëron atë rrjedhë pune dhe kur u verifikua herën e fundit. Këto tre fusha e kthejnë një listë misterioze në një politikë që dikush mund ta mbrojë.