Excepțiile VPN pentru fiecare aplicație se strică atunci când un serviciu partajat preia datele

Excludeți o aplicație din VPN și descărcarea de care avea nevoie tot eșuează sau, mai rău, începe să funcționeze și ceva nelegat se oprește. Fereastra vizibilă nu este neapărat procesul care deschide fiecare conexiune: o aplicație poate preda munca unui ajutor, unui serviciu de transfer din fundal sau unui pachet complet diferit. De aceea, o regulă pentru fiecare aplicație are nevoie de modelul real de identitate al platformei, nu de un nume familiar de fișier de pornire. Verificările de mai jos pornesc de la observație și se întorc la cine a făcut de fapt cererea.

În aceste tichete de obicei două lucruri se strică împreună: componenta greșită este exclusă, iar excepția nu este niciodată restrânsă după aceea.

Găsiți procesul, nu fereastra

Reproduceți operația eșuată și identificați procesul sau pachetul care deține conexiunea în timp ce aceasta are loc. În Windows aceasta este o întrebare diferită de ce fereastră are focusul, pentru că un transfer din fundal poate fi intermediat de un serviciu care rulează sub propria identitate. În Linux și macOS aceeași divizare apare ca procese ajutătoare și daemoni de sistem.

Notați trei detalii: identitatea executabilului sau a pachetului, destinația cu care comunica și momentul din fluxul de lucru în care s-a întâmplat. O descărcare care eșuează la început este adesea o preluare de metadate de către o altă componentă decât o descărcare care eșuează la jumătate. Doar această distincție este de obicei suficientă pentru a alege identitatea corectă înainte de a atinge regula. Dacă identitatea se dovedește a fi un serviciu și nu o aplicație, acest singur fapt schimbă întreaga regulă, așa că stabiliți-l mai întâi.

Dacă nu puteți observa procesul pentru că operația este prea scurtă, repetați-o cu o încărcătură mai mare sau cu o destinație mai lentă. Scopul este o observație reproductibilă, nu o teorie despre ce ajutor este implicat.

Tratați DNS ca pe o cale proprie

Rezolvarea numelor de sistem poate să nu urmărească deloc aplicația exclusă, motiv pentru care un browser exclus poate eșua în continuare pe un nume de gazdă privat în timp ce traficul său este corect în afara tunelului. Browserul era exclus; rezolvatorul nu.

Verificați ce face platforma cu DNS atunci când se aplică o regulă pentru fiecare aplicație și verificați separat de cererea HTTP. Dacă rezolvatorul este un serviciu partajat, el deservește fiecare aplicație de pe dispozitiv, deci excepția pe care o analizați are un public mult mai larg decât cea pe care ați testat-o.

Înregistrați care rezolvator a răspuns și prin ce interfață. Acea singură observație rezolvă o mare parte din rapoartele „aplicația este exclusă, dar numele nu se rezolvă”, așa că păstrați-o împreună cu tichetul.

Nu lărgiți un ajutor partajat

Un serviciu partajat efectuează muncă pentru mai multe aplicații, așa că excluderea lui pentru a repara un singur flux de lucru schimbă și trafic nelegat. Background Intelligent Transfer Service din Windows este un bun exemplu al formei: este infrastructură pe care multe aplicații o pot folosi, iar identitatea sa nu este identitatea aplicației care a cerut transferul.

Verificați modelul de reguli acceptat de client și cerințele organizației înainte de a adăuga acea excepție. Întrebați ce altceva folosește componenta și dacă regula pe care sunteți pe cale să o scrieți poate fi exprimată față de destinații în loc de un proces partajat.

Dacă cerința nu poate fi exprimată deloc ca graniță a aplicației, o politică bazată pe destinații sau un alt design aprobat pot fi mai ușor de înțeles și mai sigure decât o listă crescândă de excepții pentru ajutoare.

Testați întregul flux de lucru, nu pasul care eșuează

După o modificare acceptată, rulați sarcina dorită cu o cerere nouă de la început până la sfârșit. Apoi rulați un alt flux de lucru care folosește componenta partajată, pentru că acolo se anunță o ocolire largă. O corecție care o repară pe prima și o strică în tăcere pe a doua nu este o corecție. Păstrați ambele rezultate în tichet și numiți explicit al doilea flux de lucru, astfel încât un recenzent să îl poată repeta.

Păstrați testul mic și repetabil: aceeași destinație, același cont, aceleași condiții. Dacă al doilea flux de lucru nu este documentat, întrebați proprietarul de ce depinde înainte de a decide că modificarea este sigură.

Lăsați un motiv, nu o listă de nume

Documentați componenta, fluxul de lucru pe care îl deservește și motivul pentru care a fost exclusă. O listă de nume de ajutoare fără un scop asociat devine de neîntreținut în două cicluri de lansare, iar următorul inginer elimină intrarea greșită în timp ce o curăță.

O linie pentru fiecare excepție este suficientă: ce se strică fără ea, cine deține acel flux de lucru și când a fost verificat ultima dată. Acele trei câmpuri transformă o listă misterioasă într-o politică pe care cineva o poate apăra.