Hvorfor delt tunnellering ikke dekker appens oppdateringer

Du legger applikasjonen til utelukkelseslisten for delt tunnellering, appen når internett direkte, og oppdateringene feiler fortsatt eller kravler fortsatt gjennom tunnelen. Utelukkelsen virket. Den dekket bare en annen prosess enn den som utfører nedlastingen, fordi en moderne oppdaterer sjelden er den samme kjørbare filen som applikasjonsvinduet.

Myten: å utelukke appen utelukker trafikken dens

Delt tunnellering per app matcher en prosess, en pakke eller en applikasjonssti, avhengig av plattformen. Den matcher ikke et merke, en funksjon eller en brukers hensikt. Når applikasjonen overlater nedlastingen til en hjelper, en delt plattformtjeneste eller en nettleserkomponent, har den hjelperen sin egen identitet og sin egen vei gjennom tunnelen. Utelukkelseslisten aner ikke at de to prosessene tilhører samme produkt. Den vet bare hvilken du navnga.

Så regelen gjør nøyaktig det den fikk beskjed om. Antakelsen om hvem som eier overføringen var feil, og rettelsen begynner med å identifisere den eieren i stedet for å legge til flere utelukkelser.

Finn eieren av overføringen

På Android kan oppdateringen bli hentet av en delt tjenestepakke i stedet for app-pakken du utelukket, og en VPN-regel per app gjelder for pakken som åpner sockelen. På Windows kan en oppdateringstjeneste kjøre under en annen kjørbar sti enn applikasjonen, så en regel som matcher app-stien bommer på den. På macOS kan en privilegert hjelper eller en systemoppdateringsdæmon utføre overføringen mens appen bare ber om den.

Identifiser eieren ut fra bevis: plattformens visning for nettverksaktivitet, en pakkefangst filtrert på prosess eller leverandørens dokumentasjon som navngir oppdateringskomponenten. Å gjette ut fra prosessnavnet er måten to lignende binærfiler forveksles og den feilaktige utelukkes.

Oppdateringssystemer deler ofte også arbeidet. En liten metadatforespørsel sjekker en versjon, og en mye større pakkenedlasting går til en vert for innholdslevering eller et annet domene. Metadatasjekken kan lykkes gjennom tunnelen mens pakkeoverføringen stopper på en vert som tunnelen ruter annerledes. Den delingen forklarer den forvirrende rapporten der oppdateringer oppdages, men aldri installeres. Test selve pakkenedlastingen, fra samme enhet og samme nettverk, i stedet for å teste om applikasjonen åpnes.

Verifiseringen overlever en ruteendring

Å endre en rute erstatter ikke TLS, utgiveridentitet eller verifisering av pakkesignatur. Ikke slå av disse sjekkene fordi en nedlasting bare lykkes etter at du har klikket deg forbi en uforklart sertifikatadvarsel. En advarsel som bare vises på den utelukkede ruten, er et funn, ikke en hindring. Undersøk den før du utvider omveien.

På en administrert enhet, be om et støttet unntak i stedet for å legge til en bred regel for hver systemtjeneste. En regel som utelukker alle delte tjenester for å reparere én oppdaterer, utvider omveien langt utover den opprinnelige forespørselen.

Test oppdateringen, og dokumenter deretter eieren

Koble til på nytt etter endringen og verifiser den anvendte regelen igjen, fordi noen klienter bygger opp rutingen sin på nytt når tunnelen kobles til på nytt. Kjør én full oppdateringssyklus: sjekk, last ned, verifiser og installer. En vellykket sjekk beviser bare den minste delen av ruten.

Skriv ned eieren av overføringen, destinasjonsvertene og den tiltenkte ruten samme sted som regelen for delt tunnellering. Ellers vil den neste endringen i oppdateringsmekanismen stille gjøre unntaket ugyldig, og den som arver det, vil ikke ha noen måte å vite hvilken prosess regelen ble skrevet for.