Hvorfor delt tunneling ikke dækker dine apps opdateringer

Du føjer appen til udelukkelseslisten for delt tunneling, appen når internettet direkte, og opdateringerne fejler stadig eller kravler stadig gennem tunnelen. Udelukkelsen virkede. Den dækkede bare en anden proces end den, der udfører downloadet, fordi en moderne opdatering sjældent er den samme eksekverbare fil som applikationsvinduet.

Myten: at udelukke appen udelukker dens trafik

Delt tunneling for hver app matcher en proces, en pakke eller en applikationssti afhængigt af platformen. Den matcher ikke et mærke, en funktion eller en brugers hensigt. Når appen overlader downloadet til en hjælper, en delt platformstjeneste eller en browserkomponent, har den hjælper sin egen identitet og sin egen vej gennem tunnelen. Udelukkelseslisten aner ikke, at de to processer hører til det samme produkt. Den ved kun, hvilken af dem du navngav.

Så reglen gør præcis, hvad den fik besked på. Antagelsen om, hvem der ejer overførslen, var forkert, og rettelsen begynder med at identificere den ejer i stedet for at tilføje flere udelukkelser.

Find overførslens ejer

På Android kan opdateringen blive hentet af en delt tjenestepakke i stedet for den app-pakke, du udelukkede, og en VPN-regel for hver app gælder for den pakke, der åbner soklen. På Windows kan en opdateringstjeneste køre under en anden eksekverbar sti end applikationen, så en regel, der matcher app-stien, rammer den ikke. På macOS kan en privilegeret hjælper eller en systemopdateringsdæmon udføre overførslen, mens appen kun anmoder om den.

Identificer ejeren ud fra beviser: platformens visning af netværksaktivitet, en pakkeoptagelse filtreret på proces eller leverandørens dokumentation, der navngiver opdateringskomponenten. At gætte ud fra procesnavnet er måden, hvorpå to enslydende binære filer forveksles, og den forkerte udelukkes.

Opdateringssystemer deler også ofte arbejdet. En lille metadatianmodning tjekker for en version, og et meget større pakkedownload går til en værtsmaskine for indholdslevering eller et andet domæne. Metadata-tjekket kan lykkes gennem tunnelen, mens pakkeoverførslen går i stå på en vært, som tunnelen ruter anderledes. Den opdeling forklarer den forvirrende rapport, hvor opdateringer registreres, men aldrig installeres. Test selve pakkedownloadet, fra samme enhed og samme netværk, i stedet for at teste, om applikationen åbner.

Verifikation overlever en ruteændring

At ændre en rute erstatter ikke TLS, udgiveridentitet eller verifikation af pakkesignatur. Slå ikke de kontroller fra, fordi et download kun lykkes, efter du har klikket gennem en uforklaret certifikatadvarsel. En advarsel, der kun vises på den udelukkede rute, er et fund, ikke en forhindring. Undersøg den, før du udvider omvejen.

På en administreret enhed, bed om en understøttet undtagelse i stedet for at tilføje en bred regel for hver systemtjeneste. En regel, der udelukker alle delte tjenester for at rette én opdatering, udvider omvejen langt ud over den oprindelige anmodning.

Test opdateringen, og dokumentér derefter ejeren

Genopret forbindelsen efter ændringen, og bekræft den anvendte regel igen, fordi nogle klienter genopbygger deres routing, når tunnelen genoprettes. Kør en fuld opdateringscyklus: tjek, download, bekræft og installer. Et vellykket tjek beviser den mindste del af ruten.

Registrer overførslens ejer, destinationsværterne og den tilsigtede rute samme sted som reglen for delt tunneling. Ellers vil den næste ændring af opdateringsmekanismen lydløst gøre undtagelsen ugyldig, og den, der arver den, vil ikke have nogen måde at vide, for hvilken proces reglen blev skrevet.