Varför delad tunnling inte täcker appens uppdateringar

Du lägger till applikationen i undantagslistan för delad tunnling, appen når internet direkt, och uppdateringarna misslyckas fortfarande eller kryper fortfarande genom tunneln. Undantaget fungerade. Det täckte bara en annan process än den som utför nedladdningen, eftersom en modern uppdaterare sällan är samma körbara fil som applikationsfönstret.

Myten: att utesluta appen utesluter dess trafik

Delad tunnling per app matchar en process, ett paket eller en applikationssökväg, beroende på plattform. Den matchar inte ett varumärke, en funktion eller en användares avsikt. När applikationen lämnar nedladdningen till en hjälpare, en delad plattformstjänst eller en webbläsarkomponent, har den hjälparen sin egen identitet och sin egen väg genom tunneln. Undantagslistan har ingen aning om att de två processerna hör till samma produkt. Den vet bara vilken du namngav.

Så regeln gör precis vad den blev tillsagd. Antagandet om vem som äger överföringen var fel, och rättningen börjar med att identifiera den ägaren i stället för att lägga till fler undantag.

Hitta överföringens ägare

På Android kan uppdateringen hämtas av ett delat tjänstepaket i stället för det app-paket du uteslöt, och en VPN-regel per app gäller för paketet som öppnar socketen. På Windows kan en uppdateringstjänst köras under en annan körbar sökväg än applikationen, så en regel som matchar app-sökvägen missar den. På macOS kan en privilegierad hjälpare eller en systemuppdateringsdemon utföra överföringen medan appen bara begär den.

Identifiera ägaren utifrån bevis: plattformens vy för nätverksaktivitet, en paketinsamling filtrerad per process eller leverantörens dokumentation som namnger uppdateringskomponenten. Att gissa utifrån processnamnet är hur två liknande binärfiler förväxlas och den felaktiga utesluts.

Uppdateringssystem delar ofta också arbetet. En liten metadataförfrågan kontrollerar en version, och en mycket större paketnedladdning går till en värd för innehållsleverans eller en annan domän. Metadatakontrollen kan lyckas genom tunneln medan paketöverföringen fastnar hos en värd som tunneln dirigerar annorlunda. Den uppdelningen förklarar den förvirrande rapporten där uppdateringar upptäcks men aldrig installeras. Testa själva paketnedladdningen, från samma enhet och samma nätverk, i stället för att testa om applikationen öppnas.

Verifieringen överlever en ruttändring

Att ändra en rutt ersätter inte TLS, utgivarens identitet eller verifiering av paketets signatur. Stäng inte av de kontrollerna för att en nedladdning bara lyckas efter att du klickat förbi en oförklarad certifikatvarning. En varning som bara visas på den uteslutna rutten är ett fynd, inte ett hinder. Undersök den innan du utökar kringgåendet.

På en hanterad enhet, begär ett stött undantag i stället för att lägga till en bred regel för varje systemtjänst. En regel som utesluter alla delade tjänster för att reparera en enda uppdaterare utökar kringgåendet långt bortom den ursprungliga begäran.

Testa uppdateringen och dokumentera sedan ägaren

Anslut igen efter ändringen och verifiera den tillämpade regeln igen, eftersom vissa klienter bygger upp sin routing på nytt när tunneln återansluter. Kör en fullständig uppdateringscykel: kontrollera, ladda ner, verifiera och installera. En lyckad kontroll bevisar bara den minsta delen av vägen.

Anteckna överföringens ägare, målvärdarna och den avsedda rutten på samma ställe som regeln för delad tunnling. Annars gör nästa ändring av uppdateringsmekanismen undantaget ogiltigt i tysthet, och den som ärver det har ingen möjlighet att veta vilken process regeln skrevs för.