VPN-uitsluitingen per app breken wanneer een gedeelde dienst de gegevens ophaalt

U sluit één applicatie uit van de VPN en de download die nodig was mislukt nog steeds, of erger, hij begint te werken en iets anders dat er niets mee te maken heeft stopt. Het zichtbare venster is niet noodzakelijk het proces dat elke verbinding opent: een applicatie kan werk overdragen aan een helper, aan een achtergrondoverdrachtsdienst of aan een heel ander pakket. Een regel per app heeft daarom het echte identiteitsmodel van het platform nodig, niet een bekende naam van een opstartbestand. De controles hieronder beginnen bij de waarneming en gaan terug naar wie het verzoek werkelijk heeft gedaan.

In deze tickets gaan meestal twee dingen tegelijk mis: het verkeerde onderdeel wordt uitgesloten, en de uitsluiting wordt daarna nooit vernauwd.

Vind het proces, niet het venster

Reproduceer de mislukte bewerking en identificeer het proces of pakket dat de verbinding bezit terwijl die plaatsvindt. Op Windows is dat een andere vraag dan welk venster de focus heeft, omdat een achtergrondoverdracht kan worden bemiddeld door een dienst die onder zijn eigen identiteit draait. Op Linux en macOS verschijnt dezelfde splitsing als hulpprocessen en systeemdaemons.

Noteer drie details: de identiteit van het uitvoerbare bestand of het pakket, de bestemming waarmee het contact had, en het moment in de werkstroom waarop het gebeurde. Een download die aan het begin mislukt is vaak een metadata-opvraag door een ander onderdeel dan een download die halverwege mislukt. Dat verschil alleen is meestal genoeg om de juiste identiteit te kiezen voordat u de regel aanraakt. Als de identiteit een dienst blijkt te zijn en geen app, verandert dat ene feit de hele regel, dus stel dat eerst vast.

Als u het proces niet kunt observeren omdat de bewerking te kort is, herhaal haar dan met een grotere lading of een langzamer bestemming. Het doel is één reproduceerbare waarneming, niet een theorie over welke helper betrokken is.

Behandel DNS als een eigen pad

Systeemnaamresolutie volgt de uitgesloten applicatie misschien helemaal niet, waardoor een uitgesloten browser nog steeds kan falen op een privé-hostnaam terwijl het verkeer correct buiten de tunnel is. De browser was uitgesloten; de resolver niet.

Controleer wat het platform met DNS doet wanneer een regel per app geldt, en controleer dat los van het HTTP-verzoek. Als de resolver een gedeelde dienst is, bedient die elke applicatie op het apparaat, dus de uitsluiting die u overweegt heeft een veel breder publiek dan degene die u hebt getest.

Noteer welke resolver antwoordde en via welke interface. Die ene waarneming lost een groot deel van de meldingen «de app is uitgesloten maar de naam wordt niet opgelost» op, dus bewaar haar bij het ticket.

Verbreed geen gedeelde helper

Een gedeelde dienst verricht werk voor meerdere applicaties, dus het uitsluiten om één werkstroom te repareren verandert ook ongerelateerd verkeer. De Background Intelligent Transfer Service op Windows is een goed voorbeeld van de vorm: het is infrastructuur die veel applicaties kunnen gebruiken, en de identiteit ervan is niet de identiteit van de app die de overdracht aanvroeg.

Controleer het ondersteunde regelmodel van de client en de eisen van de organisatie voordat u die uitzondering toevoegt. Vraag wat de component nog meer gebruikt, en of de regel die u gaat schrijven tegen bestemmingen kan worden uitgedrukt in plaats van tegen een gedeeld proces.

Als de eis helemaal niet als applicatiegrens kan worden uitgedrukt, kan een op bestemmingen gebaseerd beleid of een ander goedgekeurd ontwerp begrijpelijker en veiliger zijn dan een groeiende lijst met helper-uitzonderingen.

Test de hele werkstroom, niet de mislukte stap

Voer na een ondersteunde wijziging de bedoelde taak uit met een nieuw verzoek van begin tot eind. Voer daarna één andere werkstroom uit die de gedeelde component gebruikt, want daar kondigt een brede omleiding zich aan. Een oplossing die de eerste repareert en de tweede stilzwijgend breekt, is geen oplossing. Bewaar beide resultaten in het ticket en noem de tweede werkstroom expliciet, zodat een beoordelaar die kan herhalen.

Houd de test klein en herhaalbaar: dezelfde bestemming, hetzelfde account, dezelfde omstandigheden. Als de tweede werkstroom niet is gedocumenteerd, vraag de eigenaar dan waarvan die afhangt voordat u besluit dat de wijziging veilig is.

Laat een reden achter, geen namenlijst

Documenteer de component, de werkstroom die hij dient en de reden dat hij werd uitgesloten. Een lijst met helper-namen zonder verbonden doel wordt binnen twee releasecycli onbeheerbaar, en de volgende engineer verwijdert de verkeerde vermelding terwijl hij hem opruimt.

Eén regel per uitzondering is genoeg: wat er zonder breekt, wie die werkstroom bezit, en wanneer die voor het laatst is geverifieerd. Die drie velden maken van een raadselachtige lijst een beleid dat iemand kan verdedigen.