Undtagelser i VPN pr. app bryder sammen, når en delt tjeneste henter data

Du undtager én applikation fra VPN’en, og den download, den havde brug for, fejler stadig, eller værre, den begynder at virke, og noget urelateret stopper. Det synlige vindue er ikke nødvendigvis den proces, der åbner hver forbindelse: en applikation kan overdrage arbejde til en hjælper, en baggrundsoverførselstjeneste eller en helt anden pakke. En regel pr. app kræver derfor platformens egentlige identitetsmodel frem for et velkendt launcher-filnavn. Kontrollerne nedenfor starter ved observationen og arbejder tilbage til den, der faktisk sendte anmodningen.

To ting går som regel galt på samme tid i disse sager: den forkerte komponent undtages, og undtagelsen indsnævres aldrig bagefter.

Find processen, ikke vinduet

Genskab den mislykkede handling, og identificér den proces eller pakke, der ejer forbindelsen, mens den sker. På Windows er det et andet spørgsmål end hvilket vindue, der har fokus, fordi en baggrundsoverførsel kan formidles af en tjeneste, der kører under sin egen identitet. På Linux og macOS viser samme opdeling sig som hjælpeprocesser og systemdaemons.

Skriv tre detaljer ned: kørselsfilens eller pakkens identitet, det mål, den kontaktede, og det øjeblik i arbejdsgangen, hvor det skete. En download, der fejler i starten, er ofte et metadatahent af en anden komponent end en download, der fejler halvvejs. Den forskel alene er som regel nok til at vælge den rigtige identitet, før du rører reglen. Hvis identiteten viser sig at være en tjeneste og ikke en app, ændrer den ene kendsgerning hele reglen, så fastslå den først.

Hvis du ikke kan observere processen, fordi handlingen er for kort, så gentag den med en større nyttelast eller et langsommere mål. Målet er én reproducerbar observation, ikke en teori om, hvilken hjælper der er involveret.

Behandl DNS som sin egen vej

Systemets navneopløsning følger måske slet ikke den undtagne applikation, og derfor kan en undtagen browser stadig fejle på et privat værtsnavn, mens dens trafik korrekt er uden for tunnelen. Browseren var undtaget; opløseren var ikke.

Kontrollér, hvad platformen gør med DNS, når en regel pr. app gælder, og kontrollér det adskilt fra HTTP-anmodningen. Hvis opløseren er en delt tjeneste, betjener den hver applikation på enheden, så den undtagelse, du overvejer, har et meget bredere publikum end den, du testede.

Notér, hvilken opløser der svarede, og gennem hvilken grænseflade. Den ene observation afgør en stor del af rapporterne «appen er undtaget, men navnet opløses ikke», så gem den sammen med sagen.

Udvid ikke en delt hjælper

En delt tjeneste udfører arbejde for flere applikationer, så at undtage den for at reparere én arbejdsgang ændrer også urelateret trafik. Background Intelligent Transfer Service på Windows er et godt eksempel på formen: det er infrastruktur, som mange applikationer kan bruge, og dens identitet er ikke identiteten af den app, der anmodede om overførslen.

Kontrollér den regelmodel, klienten understøtter, og organisationens krav, før du føjer den undtagelse til. Spørg, hvad der ellers bruger komponenten, og om den regel, du er ved at skrive, kan udtrykkes mod mål i stedet for mod en delt proces.

Hvis kravet slet ikke kan udtrykkes som en applikationsgrænse, kan en målorienteret politik eller et andet godkendt design være mere forståeligt og sikrere end en voksende liste af hjælperundtagelser.

Test hele arbejdsgangen, ikke det fejlende trin

Kør den tilsigtede opgave med en frisk anmodning fra start til slut efter en understøttet ændring. Kør derefter én anden arbejdsgang, der bruger den delte komponent, for det er der, en bred omvej melder sig. En rettelse, der reparerer den første og lydløst ødelægger den anden, er ikke en rettelse. Gem begge resultater i sagen, og navngiv den anden arbejdsgang udtrykkeligt, så en anmelder kan gentage den.

Hold testen lille og gentagelig: samme mål, samme konto, samme betingelser. Hvis den anden arbejdsgang ikke er dokumenteret, så spørg dens ejer, hvad den afhænger af, før du beslutter, at ændringen er sikker.

Efterlad en grund, ikke en navneliste

Dokumentér komponenten, den arbejdsgang den tjener, og grunden til, at den blev undtaget. En liste af hjælpernavne uden tilknyttet formål bliver uholdbar inden for to udgivelsescyklusser, og den næste ingeniør fjerner den forkerte post, mens han rydder op.

Én linje pr. undtagelse er nok: hvad der brækker uden den, hvem der ejer den arbejdsgang, og hvornår den sidst blev verificeret. De tre felter gør en mystisk liste til en politik, nogen kan forsvare.