En sekundær VPN tilhører én Wi-Fi-profil, ikke alle

Konfigurer en VPN som sekundær for hjemmets Wi-Fi-forbindelse, og alt fungerer, helt til maskinen kobler seg til et annet tilgangspunkt og tunnelen blir liggende nede. Den nye forbindelsen er et eget konfigurasjonsobjekt med sin egen UUID, og den har ingen grunn til å kjenne båndet du opprettet for forgjengeren. Ingenting gikk i stykker; tilknytningen fantes rett og slett aldri.

Tilkoblingsreferansen til NetworkManager definerer sekundære som UUID-er som aktiveres sammen med en bestemt basisforbindelse. Den bemerker også at vanlige VPN-profiler ikke implementerer automatisk aktivering slik basisforbindelser gjør. Begge utsagnene peker mot samme konklusjon: tilknytningen er per profil, og noen må opprette den for hver nye.

Hva en sekundær egentlig er

En basisforbindelse har en identitet, en UUID og en liste over sekundære. Når den aktiveres, aktiverer behandleren også disse sekundære i rekkefølge, og det er slik en VPN følger et Wi-Fi-nettverk uten et manuelt klikk. Relasjonen ligger på basisforbindelsen, skrevet som UUID-strenger i stedet for navn. Det valget av representasjon er ikke tilfeldig; det er det som gjør at tilknytningen overlever en omdøping.

Den detaljen om navn betyr mer enn den ser ut til. Omdøping av en VPN-profil lar UUID-en være urørt, slik at eksisterende tilknytninger fortsetter å virke. Sletting av den gamle profilen og import av en ny gir en ny UUID, og hver tilknytning som pekte på den gamle, peker nå på ingenting.

Undersøk den eksisterende listen før du legger til. En hjemprofil med én sekundær er ikke en regel som passer på hvert SSID; det er én rad i ett objekt, og den blir ikke spurt når en annen basis aktiveres.

Plasser tilknytningen der profilene opprettes

På en personlig maskin gjør du vedleggingen av den tiltenkte sekundære til en del av å legge til hver tillatt Wi-Fi-profil. Det er en vane snarere enn en funksjon, men en vane som gir en konsistent tilstand, og den koster én kommando eller to dialogbesøk per nettverk. Hold en kort notat om hvilke nettverk som skal bære tunnelen, fordi listen er policyen.

På administrerte enheter bør provisjoneringsflyten opprette Wi-Fi-oppføringen og dens VPN-tilknytning i samme trinn, og bruke samme behandling på tillatte profiler som allerede finnes. Å distribuere en VPN-profil alene lar basisrelasjonene være uspesifiserte, og det er slik en flåte ender opp med en tunnel som bare halvparten av maskinene bruker.

Der brukere fortsatt kan opprette profiler utenfor den administrerte veien, må du bestemme eksplisitt hva som skjer med disse oppføringene. Å anta at de arver en tilknytning er ikke en policy; det er et håp med en støttekostnad.

Planlegg for at VPN-ens identitet endres

Provisjoneringskilden trenger UUID-en til den tiltenkte VPN-en, ikke et visningsnavn noen har gjettet. Når vedlikehold erstatter den VPN-en med et nyimportert objekt, oppdaterer du provisjoneringsmalen og de berørte eksisterende tilknytningene i samme endring. En omdøping er ikke en erstatning, og å behandle de to som likeverdige er hvordan en fungerende utrullering bryter sammen en uke senere.

Oppbevar UUID-en ved siden av grunnen til at den finnes. En fremtidig ingeniør som finner en bar UUID i en liste over sekundære, kan ikke avgjøre om den er gjeldende, og sletter den sannsynligvis under opprydding.

Aktivering er ikke håndheving

En forespørsel om sekundær skjer på aktiveringstidspunktet. Den blokkerer ikke programmer i intervallet før autentiseringen er fullført, og den stopper ikke trafikk etter at tunnelen feiler. Dette er forskjellige egenskaper levert av forskjellige mekanismer, og å blande dem gir et design som ser strengt ut i profilen og er ettergivende i praksis.

Blokkering av direkte trafikk er en egen funksjon med sin egen konfigurasjon og sine egne feilmoduser, og den må ta hensyn til trafikken som må nå nettverket før noen tunnel kan eksistere: captive-portaler, påloggingssider, selve endepunktet. En blokkeringspolicy som ikke kan oppfylles før autentisering, låser maskinen ute fra nettopp det nettverket den trenger.

Sett den forskjellen inn i instruksjonene brukerne faktisk leser. Et nytt Wi-Fi-nettverk kan be om tunnelen; håndhevingen avgjør om noe får gå ut når den ikke kan koble til. Brukere som bare får fortalt den første halvdelen, vil rapportere designet som ødelagt.

Test med en virkelig ny profil

Bruk et godkjent testnettverk og en nyopprettet basisprofil, ikke hjemmeoppføringen som allerede virker. Observer basisaktiveringen, den forespurte sekundære UUID-en og eventuell autentiseringsforespørsel i rekkefølge, og noter hvilket trinn som stopper når det stopper. En hemmelig agent som blir tilgjengelig etter innlogging på skrivebordet, er ikke automatisk til stede i hver oppstartskontekst, så en omstart hører med i testplanen. Kontroller deretter den tiltenkte ressursen og feilveien: kommer tunnelen opp før programmet trenger den, og hva skjer med det programmet når autentiseringen feiler?

Kontroller deretter den tiltenkte ressursen og feilveien: kommer tunnelen opp før programmet trenger den, og hva skjer med det programmet når tunnelen ikke kan autentisere? De to observasjonene er akseptkriteriene, og ingen av dem er synlig i selve profilen.