De ce tunelarea divizată nu acoperă actualizările aplicației tale

Adaugi aplicația în lista de excluderi a tunelării divizate, aplicația ajunge la internet direct, iar actualizările tot eșuează sau încă se târăsc prin tunel. Excluderea a funcționat. A acoperit doar un alt proces decât cel care face descărcarea, pentru că un actualizator modern este rareori același executabil ca fereastra aplicației.

Mitul: excluderea aplicației exclude traficul ei

Tunelarea divizată pe aplicație potrivește un proces, un pachet sau o cale a aplicației, în funcție de platformă. Nu potrivește un brand, o funcție sau intenția utilizatorului. Când aplicația predă descărcarea unui ajutor, unui serviciu de platformă partajat sau unei componente de browser, acel ajutor are propria identitate și propria cale prin tunel. Lista de excluderi nu are nicio idee că cele două procese aparțin aceluiași produs. Știe doar pe care l-ai numit.

Deci regula face exact ce i s-a spus. Presupunerea despre cine deține transferul a fost greșită, iar remedierea începe cu identificarea acelui proprietar, nu cu adăugarea altor excluderi.

Găsește proprietarul transferului

Pe Android, actualizarea poate fi adusă de un pachet de serviciu partajat în locul pachetului aplicației pe care l-ai exclus, iar o regulă VPN pe aplicație se aplică pachetului care deschide socketul. Pe Windows, un serviciu de actualizare poate rula sub o cale executabilă diferită de aplicație, așa că o regulă care corespunde căii aplicației îl ratează. Pe macOS, un ajutor privilegiat sau un demon de actualizare a sistemului poate face transferul în timp ce aplicația doar îl cere.

Identifică proprietarul pe baza dovezilor: vizualizarea activității de rețea a platformei, o captură de pachete filtrată pe proces sau documentația furnizorului care numește componenta de actualizare. Ghiceala după numele procesului este felul în care două binare asemănătoare se confundă și cel greșit este exclus.

Sistemele de actualizare împart adesea și munca. O cerere mică de metadate verifică o versiune, iar o descărcare de pachet mult mai mare merge către un host de livrare a conținutului sau către alt domeniu. Verificarea metadatelor poate reuși prin tunel în timp ce transferul pachetului se blochează pe un host pe care tunelul îl rutează altfel. Această împărțire explică raportul confuz în care actualizările sunt detectate dar nu sunt instalate niciodată. Testează descărcarea pachetului în sine, de pe același dispozitiv și aceeași rețea, în loc să testezi dacă aplicația se deschide.

Verificarea supraviețuiește unei schimbări de rută

Schimbarea unei rute nu înlocuiește TLS, identitatea editorului sau verificarea semnăturii pachetului. Nu dezactiva acele verificări pentru că o descărcare reușește doar după ce treci de un avertisment de certificat neexplicat. Un avertisment care apare doar pe ruta exclusă este o constatare, nu un obstacol. Investighează-l înainte de a lărgi ocolul.

Pe un dispozitiv administrat, cere o excepție acceptată în loc să adaugi o regulă largă pentru fiecare serviciu de sistem. O regulă care exclude toate serviciile partajate pentru a repara un singur actualizator lărgește ocolul mult dincolo de cererea inițială.

Testează actualizarea, apoi documentează proprietarul

Reconectează-te după schimbare și verifică din nou regula aplicată, pentru că unii clienți își reconstruiesc rutarea când tunelul se reconectează. Rulează un ciclu complet de actualizare: verifică, descarcă, confirmă și instalează. O verificare reușită dovedește doar cea mai mică parte a căii.

Notează proprietarul transferului, hosturile de destinație și ruta dorită în același loc cu regula de tunelare divizată. Altfel, următoarea schimbare a mecanismului de actualizare va invalida excepția în tăcere, iar persoana care o moștenește nu va avea cum să știe pentru ce proces a fost scrisã regula.