Per-app VPN-unntak bryt saman når ei delt teneste hentar data

Du utelukkar éin applikasjon frå VPN-en, og nedlastinga han trong feilar framleis, eller verre, ho byrjar å verke og noko urelatert stoppar. Det synlege vindauget er ikkje nødvendigvis prosessen som opnar kvar tilknyting: ein applikasjon kan overlete arbeidet til ein hjelpar, ei bakgrunnsoverføringsteneste eller ein heilt annan pakke. Ei regel per app treng difor den eigentlege identitetsmodellen til plattforma, ikkje eit kjent startfilnamn. Kontrollane nedanfor byrjar ved observasjonen og går tilbake til den som faktisk sende førespurnaden.

I desse sakene går som regel to ting gale samstundes: feil komponent blir utelukka, og unntaket blir aldri innsnevra etterpå.

Finn prosessen, ikkje vindauget

Reproduser den mislukka operasjonen og identifiser prosessen eller pakken som eig tilknytinga medan ho skjer. På Windows er dette eit anna spørsmål enn kva vindauge som har fokus, fordi ei bakgrunnsoverføring kan bli formidla av ei teneste som køyrer under sin eigen identitet. På Linux og macOS viser den same delinga seg som hjelpeprosessar og systemdaemonar.

Skriv ned tre detaljar: identiteten til køyrbar fil eller pakke, målet ho kontakta, og augneblinken i arbeidsflyten då det skjedde. Ei nedlasting som feilar i starten er ofte eit metadatahent av ein annan komponent enn ei nedlasting som feilar halvvegs. Den skilnaden åleine er som regel nok til å velje rett identitet før du rører regelen. Viss identiteten viser seg å vere ei teneste og ikkje ein app, endrar denne eine kjensgjerninga heile regelen, så fastslå han først.

Viss du ikkje kan observere prosessen fordi operasjonen er for kort, gjer han om att med ei større last eller eit seinare mål. Målet er éin reproduserbar observasjon, ikkje ein teori om kva hjelpar som er involvert.

Behandle DNS som sin eigen veg

Namneoppslag i systemet følgjer kanskje ikkje den utelukka applikasjonen i det heile, og difor kan ein utelukka nettlesar framleis feile på eit privat vertsnamn medan trafikken er rett utanfor tunnelen. Nettlesaren var utelukka; oppløysaren var ikkje.

Kontroller kva plattforma gjer med DNS når ei regel per app gjeld, og kontroller det skilt frå HTTP-førespurnaden. Viss oppløysaren er ei delt teneste, tener ho kvar applikasjon på eininga, så unntaket du vurderer har eit mykje breiare publikum enn det du testa.

Noter kva oppløysar som svara og gjennom kva grensesnitt. Den eine observasjonen løyser ein stor del av rapportane «appen er utelukka, men namnet blir ikkje løyst», så ta han vare på saman med saka.

Ikkje utvid ein delt hjelpar

Ei delt teneste utfører arbeid for fleire applikasjonar, så å utelukke ho for å reparere éin arbeidsflyt endrar også urelatert trafikk. Background Intelligent Transfer Service på Windows er eit godt døme på forma: det er infrastruktur som mange applikasjonar kan bruke, og identiteten er ikkje identiteten til appen som bad om overføringa.

Kontroller regelmodellen klienten støttar og krava til organisasjonen før du legg til dette unntaket. Spør kva anna som brukar komponenten, og om regelen du er i ferd med å skrive kan uttrykkjast mot mål i staden for mot ein delt prosess.

Viss kravet ikkje kan uttrykkjast som ein applikasjonsgrense i det heile, kan ein målbasert politikk eller ei anna godkjend utforming vere meir forståeleg og tryggare enn ei veksande liste med hjelparunntak.

Test heile arbeidsflyten, ikkje trinnet som feilar

Etter ei støtta endring, køyr den tiltenkte oppgåva med ein fersk førespurnad frå start til slutt. Køyr deretter éin annan arbeidsflyt som brukar den delte komponenten, for det er der ein brei omgåing melder seg. Ei retting som reparerer den første og stille øydelegg den andre er ikkje ei retting. Ta vare på begge resultata i saka og namngje den andre arbeidsflyten eksplisitt, slik at ein gjennomgåar kan gjenta han.

Hald testen liten og repeterbar: same mål, same konto, same vilkår. Viss den andre arbeidsflyten ikkje er dokumentert, spør eigaren kva han avheng av før du avgjer at endringa er trygg.

Lat det stå att ein grunn, ikkje ei namneliste

Dokumenter komponenten, arbeidsflyten han tener og grunnen til at han blei utelukka. Ei liste med hjelparnamn utan tilknytt formål blir uhåndterleg innan to utgåvesyklusar, og den neste ingeniøren fjernar feil oppføring medan han ryddar henne opp.

Éi line per unntak er nok: kva som bryt utan det, kven som eig den arbeidsflyten, og når han sist blei verifisert. Dei tre felta gjer ei mystisk liste om til ein politikk nokon kan forsvare.