Kvifor delt tunnellering ikkje dekkjer oppdateringane til appen

Du legg applikasjonen til utelukkingslista for delt tunnellering, appen når internett direkte, og oppdateringane feilar framleis eller krev framleis gjennom tunnelen. Utelukkinga verka. Ho dekte berre ein annan prosess enn den som gjer nedlastinga, fordi ein moderne oppdaterar sjeldan er den same køyrbare fila som applikasjonsvindauget.

Myten: å utelukke appen utelukkar trafikken hans

Delt tunnellering per app matchar ein prosess, ein pakke eller ein applikasjonssti, avhengig av plattforma. Ho matchar ikkje eit merke, ein funksjon eller eit brukarønske. Når applikasjonen overlet nedlastinga til ein hjelpar, ei delt plattformteneste eller ein nettlesarkomponent, har den hjelparen sin eigen identitet og sin eigen veg gjennom tunnelen. Utelukkingslista veit ikkje at dei to prosessane høyrer til same produkt. Ho veit berre kven du namngav.

Så regelen gjer nøyaktig det han fekk beskjed om. Føresetnaden om kven som eig overføringa var feil, og rettinga byrjar med å identifisere den eigaren i staden for å leggje til fleire utelukkingar.

Finn eigaren av overføringa

På Android kan oppdateringa bli henta av ein delt tenestepakke i staden for app-pakken du utelukka, og ein VPN-regel per app gjeld for pakken som opnar sockelen. På Windows kan ein oppdateringsteneste køyre under ein annan køyrbar sti enn applikasjonen, så ein regel som matchar app-stien bommar på han. På macOS kan ein privilegert hjelpar eller ein systemoppdateringsdemon gjere overføringa medan appen berre ber om ho.

Identifiser eigaren ut frå bevis: visninga for nettverksaktivitet på plattforma, ein pakkefangst filtrert på prosess eller dokumentasjonen til leverandøren som namngir oppdateringskomponenten. Å gjette ut frå prosessnamnet er måten to liknande binærfiler blir forveksla og den feilaktige blir utelukka.

Oppdateringssystem deler ofte også arbeidet. Ei lita metadatførespurnad sjekkar ein versjon, og ei mykje større pakkenedlasting går til ein vert for innhaldslevering eller eit anna domene. Metadatasjekken kan lykkast gjennom tunnelen medan pakkeoverføringa stoppar på ein vert som tunnelen rutar annleis. Den delinga forklarer den forvirrande rapporten der oppdateringar blir oppdaga, men aldri installerte. Test sjølve pakkenedlastinga, frå same eining og same nettverk, i staden for å teste om applikasjonen opnar.

Verifiseringa overlever ei ruteendring

Å endre ei rute erstattar ikkje TLS, utgjevaridentitet eller verifisering av pakkesignatur. Ikkje slå av desse sjekkane fordi ei nedlasting berre lykkast etter at du har klikka deg forbi ei uforklart sertifikatåtvaring. Ei åtvaring som berre viser seg på den utelukka ruta, er eit funn, ikkje ein hindring. Gransk ho før du utvidar omvegen.

På ei administrert eining, be om eit støtta unntak i staden for å leggje til ein brei regel for kvar systemteneste. Ein regel som utelukkar alle delte tenester for å reparere éin oppdaterar, utvidar omvegen langt utover den opphavlege førespurnaden.

Test oppdateringa, og dokumenter deretter eigaren

Kopla til på nytt etter endringa og verifiser den brukte regelen igjen, fordi nokre klientar byggjer opp ruttinga si på nytt når tunnelen blir kopla til på nytt. Køyr éin full oppdateringssyklus: sjekk, last ned, verifiser og installer. Ein vellukka sjekk beviser berre den minste delen av ruta.

Skriv ned eigaren av overføringa, målvertane og den tiltenkte ruta på same stad som regelen for delt tunnellering. Elles vil den neste endringa i oppdateringsmekanismen stille gjere unntaket ugyldig, og den som arvar det, vil ikkje ha nokon måte å vite kva prosess regelen vart skriven for.