Per-app VPN-unntak bryter sammen når en delt tjeneste henter data

Du utelukker én applikasjon fra VPN-en, og nedlastingen den trengte feiler fortsatt, eller verre, den begynner å virke og noe urelatert stopper. Det synlige vinduet er ikke nødvendigvis prosessen som åpner hver tilkobling: en applikasjon kan overlate arbeidet til en hjelper, en bakgrunnsoverføringstjeneste eller en helt annen pakke. En regel per app trenger derfor plattformens egentlige identitetsmodell, ikke et kjent startfilnavn. Kontrollene nedenfor starter ved observasjonen og går tilbake til den som faktisk sendte forespørselen.

I disse sakene går som regel to ting galt samtidig: feil komponent utelukkes, og unntaket innsnevres aldri etterpå.

Finn prosessen, ikke vinduet

Reproduser den mislykkede operasjonen og identifiser prosessen eller pakken som eier tilkoblingen mens den skjer. På Windows er dette et annet spørsmål enn hvilket vindu som har fokus, fordi en bakgrunnsoverføring kan formidles av en tjeneste som kjører under sin egen identitet. På Linux og macOS viser den samme delingen seg som hjelpeprosesser og systemdaemoner.

Skriv ned tre detaljer: identiteten til kjørbar fil eller pakke, målet den kontaktet, og øyeblikket i arbeidsflyten da det skjedde. En nedlasting som feiler i starten er ofte et metadatahent av en annen komponent enn en nedlasting som feiler halvveis. Den forskjellen alene er som regel nok til å velge riktig identitet før du rører regelen. Hvis identiteten viser seg å være en tjeneste og ikke en app, endrer den ene kjensgjerningen hele regelen, så fastslå den først.

Hvis du ikke kan observere prosessen fordi operasjonen er for kort, gjenta den med en større nyttelast eller et langsommere mål. Målet er én reproduserbar observasjon, ikke en teori om hvilken hjelper som er involvert.

Behandle DNS som sin egen vei

Systemets navneoppslag følger kanskje ikke den utelukkede applikasjonen i det hele tatt, og derfor kan en utelukket nettleser fortsatt feile på et privat vertsnavn mens trafikken er korrekt utenfor tunnelen. Nettleseren var utelukket; oppløseren var ikke.

Kontroller hva plattformen gjør med DNS når en regel per app gjelder, og kontroller det atskilt fra HTTP-forespørselen. Hvis oppløseren er en delt tjeneste, betjener den hver applikasjon på enheten, så unntaket du vurderer har et mye bredere publikum enn det du testet.

Noter hvilken oppløser som svarte og gjennom hvilket grensesnitt. Den ene observasjonen løser en stor del av rapportene «appen er utelukket, men navnet løses ikke», så ta den vare på sammen med saken.

Ikke utvid en delt hjelper

En delt tjeneste utfører arbeid for flere applikasjoner, så å utelukke den for å reparere én arbeidsflyt endrer også urelatert trafikk. Background Intelligent Transfer Service på Windows er et godt eksempel på formen: det er infrastruktur som mange applikasjoner kan bruke, og identiteten er ikke identiteten til appen som ba om overføringen.

Kontroller regelmodellen klienten støtter og organisasjonens krav før du legger til det unntaket. Spør hva annet som bruker komponenten, og om regelen du er i ferd med å skrive kan uttrykkes mot mål i stedet for mot en delt prosess.

Hvis kravet ikke kan uttrykkes som en applikasjonsgrense i det hele tatt, kan en målbasert policy eller en annen godkjent utforming være mer forståelig og tryggere enn en voksende liste med hjelperunntak.

Test hele arbeidsflyten, ikke trinnet som feiler

Etter en støttet endring, kjør den tiltenkte oppgaven med en fersk forespørsel fra start til slutt. Kjør deretter én annen arbeidsflyt som bruker den delte komponenten, for det er der en bred omgåelse melder seg. En rettelse som reparerer den første og stille ødelegger den andre er ikke en rettelse. Ta vare på begge resultatene i saken og navngi den andre arbeidsflyten eksplisitt, slik at en gjennomgåer kan gjenta den.

Hold testen liten og repeterbar: samme mål, samme konto, samme betingelser. Hvis den andre arbeidsflyten ikke er dokumentert, spør eieren hva den avhenger av før du bestemmer at endringen er trygg.

La det stå igjen en grunn, ikke en navneliste

Dokumenter komponenten, arbeidsflyten den tjener og grunnen til at den ble utelukket. En liste med hjelpernavn uten tilknyttet formål blir uholdbar innen to utgivelsessykluser, og den neste ingeniøren fjerner feil oppføring mens han rydder den opp.

Én linje per unntak er nok: hva som bryter uten det, hvem som eier den arbeidsflyten, og når den sist ble verifisert. De tre feltene gjør en mystisk liste om til en policy noen kan forsvare.