Per-app-VPN-undantag bryts när en delad tjänst hämtar data

Du undantar ett program från VPN och nedladdningen det behövde misslyckas fortfarande, eller värre, den börjar fungera och något orelaterat stannar. Det synliga fönstret är inte nödvändigtvis processen som öppnar varje anslutning: ett program kan lämna arbetet till en hjälpare, en bakgrundsöverföringstjänst eller ett helt annat paket. En regel per app behöver därför plattformens verkliga identitetsmodell, inte ett bekant startfilnamn. Kontrollerna nedan börjar vid observationen och går tillbaka till den som faktiskt skickade begäran.

I dessa ärenden går oftast två saker fel samtidigt: fel komponent undantas, och undantaget snävas aldrig in efteråt.

Hitta processen, inte fönstret

Reproducera den misslyckade åtgärden och identifiera processen eller paketet som äger anslutningen medan den sker. I Windows är detta en annan fråga än vilket fönster som har fokus, eftersom en bakgrundsöverföring kan förmedlas av en tjänst som körs under sin egen identitet. I Linux och macOS visar sig samma uppdelning som hjälpprocesser och systemdaemoner.

Skriv ned tre detaljer: identiteten för den körbara filen eller paketet, målet den kontaktade och ögonblicket i arbetsflödet då det hände. En nedladdning som misslyckas i början är ofta ett metadatahämtning av en annan komponent än en nedladdning som misslyckas halvvägs. Den skillnaden brukar räcka för att välja rätt identitet innan du rör regeln. Om identiteten visar sig vara en tjänst och inte en app ändrar det ena faktum hela regeln, så fastställ den först.

Om du inte kan observera processen eftersom åtgärden är för kort, upprepa den med en större nyttolast eller ett långsammare mål. Målet är en reproducerbar observation, inte en teori om vilken hjälpare som är inblandad.

Behandla DNS som sin egen väg

Systemets namnmatchning kanske inte följer det undantagna programmet alls, och därför kan en undantagen webbläsare fortfarande misslyckas på ett privat värdnamn medan trafiken korrekt ligger utanför tunneln. Webbläsaren var undantagen; matcharen var det inte.

Kontrollera vad plattformen gör med DNS när en regel per app gäller, och kontrollera det separat från HTTP-begäran. Om matcharen är en delad tjänst betjänar den varje program på enheten, så undantaget du överväger har en mycket bredare publik än det du testade.

Notera vilken matchare som svarade och genom vilket gränssnitt. Den enda observationen löser en stor del av rapporterna ”appen är undantagen men namnet matchas inte”, så spara den med ärendet.

Utöka inte en delad hjälpare

En delad tjänst utför arbete för flera program, så att undanta den för att reparera ett arbetsflöde ändrar också orelaterad trafik. Background Intelligent Transfer Service i Windows är ett bra exempel på formen: det är infrastruktur som många program kan använda, och dess identitet är inte identiteten för appen som begärde överföringen.

Kontrollera den regelmodell klienten stöder och organisationens krav innan du lägger till det undantaget. Fråga vad annat som använder komponenten, och om regeln du är på väg att skriva kan uttryckas mot mål i stället för mot en delad process.

Om kravet inte alls kan uttryckas som en programgräns kan en målbaserad policy eller en annan godkänd utformning vara mer begriplig och säkrare än en växande lista med hjälparundantag.

Testa hela arbetsflödet, inte steget som misslyckas

Efter en stödd ändring, kör den avsedda uppgiften med en färsk begäran från början till slut. Kör sedan ett annat arbetsflöde som använder den delade komponenten, för det är där en bred kringgående annonserar sig. En rättelse som reparerar det första och tyst bryter det andra är ingen rättelse. Spara båda resultaten i ärendet och namnge det andra arbetsflödet uttryckligen, så att en granskare kan upprepa det.

Håll testet litet och repeterbart: samma mål, samma konto, samma villkor. Om det andra arbetsflödet inte är dokumenterat, fråga dess ägare vad det beror på innan du avgör att ändringen är säker.

Lämna en anledning, inte en nammlista

Dokumentera komponenten, arbetsflödet den tjänar och anledningen till att den undantogs. En lista med hjälparnamn utan kopplat syfte blir ohanterbar inom två utgivningscykler, och nästa ingenjör tar bort fel post medan han städar den.

En rad per undantag räcker: vad som bryts utan det, vem som äger det arbetsflödet och när det senast verifierades. De tre fälten förvandlar en mystisk lista till en policy som någon kan försvara.