Waarom gesplitste tunneling de updates van je app niet dekt

Je voegt de applicatie toe aan de uitsluitingslijst van gesplitste tunneling, de app bereikt het internet rechtstreeks, en de updates mislukken nog steeds of kruipen nog steeds door de tunnel. De uitsluiting werkte. Ze dekte alleen een ander proces dan het proces dat de download uitvoert, omdat een moderne updater zelden hetzelfde uitvoerbare bestand is als het applicatievenster.

De mythe: de app uitsluiten sluit het verkeer uit

Gesplitste tunneling per app koppelt aan een proces, een pakket of een applicatiepad, afhankelijk van het platform. Het koppelt niet aan een merk, een functie of een bedoeling van de gebruiker. Wanneer de applicatie de download overdraagt aan een helper, een gedeelde platformdienst of een browsercomponent, heeft die helper zijn eigen identiteit en zijn eigen pad door de tunnel. De uitsluitingslijst heeft geen idee dat de twee processen bij hetzelfde product horen. Ze weet alleen welke je hebt genoemd.

Dus de regel doet precies wat hem is opgedragen. De aanname over wie de overdracht bezit, was fout, en de oplossing begint met het identificeren van die eigenaar in plaats van het toevoegen van meer uitsluitingen.

Vind de eigenaar van de overdracht

Op Android kan de update worden opgehaald door een gedeeld dienstpakket in plaats van door het app-pakket dat je hebt uitgesloten, en een VPN-regel per app geldt voor het pakket dat de socket opent. Op Windows kan een updater-dienst onder een ander uitvoerbaar pad draaien dan de applicatie, dus een regel die bij het app-pad past, mist hem. Op macOS kan een bevoorrechte helper of een systeem-updatedaemon de overdracht uitvoeren terwijl de app er alleen om vraagt.

Identificeer de eigenaar op basis van bewijs: de netwerkactiviteitsweergave van het platform, een pakketopname gefilterd op proces, of de documentatie van de leverancier die de updater-component noemt. Raden op basis van de procesnaam is hoe twee op elkaar lijkende binaire bestanden worden verwisseld en de verkeerde wordt uitgesloten.

Updatesystemen verdelen het werk ook vaak. Een klein metadataverzoek controleert een versie, en een veel grotere pakketdownload gaat naar een contentdeliveryhost of een ander domein. De metadatacontrole kan via de tunnel slagen terwijl de pakketoverdracht vastloopt op een host die de tunnel anders routeert. Die splitsing verklaart het verwarrende rapport waarin updates worden gedetecteerd maar nooit geïnstalleerd. Test de pakketdownload zelf, vanaf hetzelfde apparaat en hetzelfde netwerk, in plaats van te testen of de applicatie opent.

Verificatie overleeft een routewijziging

Een route wijzigen vervangt TLS, de identiteit van de uitgever of de verificatie van de pakketsignatuur niet. Schakel die controles niet uit omdat een download pas slaagt nadat je een onverklaarde certificaatwaarschuwing hebt weggeklikt. Een waarschuwing die alleen op het uitgesloten pad verschijnt, is een bevinding, geen obstakel. Onderzoek het voordat je de omleiding verbreedt.

Op een beheerd apparaat, vraag om een ondersteunde uitzondering in plaats van een brede regel voor elke systeemdienst toe te voegen. Een regel die alle gedeelde diensten uitsluit om één updater te repareren, verbreedt de omleiding ver voorbij het oorspronkelijke verzoek.

Test de update en documenteer daarna de eigenaar

Maak opnieuw verbinding na de wijziging en verifieer de toegepaste regel opnieuw, omdat sommige clients hun routering opnieuw opbouwen wanneer de tunnel opnieuw verbindt. Voer één volledige updatecyclus uit: controleren, downloaden, verifiëren en installeren. Een geslaagde controle bewijst alleen het kleinste deel van het pad.

Leg de eigenaar van de overdracht, de bestemmingshosts en de beoogde route vast op dezelfde plek als de regel voor gesplitste tunneling. Anders maakt de volgende wijziging in het updatemechanisme de uitzondering stilzwijgend ongeldig, en wie haar erft, heeft geen manier om te weten voor welk proces de regel is geschreven.