En sekundär VPN tillhör en Wi-Fi-profil, inte alla

Konfigurera en VPN som sekundär till hemmets Wi-Fi-anslutning och allt fungerar, tills datorn ansluter till en annan åtkomstpunkt och tunneln ligger kvar nere. Den nya anslutningen är ett eget konfigurationsobjekt med sitt eget UUID, och den har ingen anledning att känna till bandet du skapade för dess föregångare. Inget gick sönder; kopplingen fanns helt enkelt aldrig.

NetworkManagers anslutningsreferens definierar sekundära som UUID:n som aktiveras tillsammans med en viss basanslutning. Den noterar också att vanliga VPN-profiler inte implementerar automatisk aktivering så som basanslutningar gör. Båda påståendena leder till samma slutsats: kopplingen gäller per profil, och någon måste skapa den för varje ny.

Vad en sekundär egentligen är

En basanslutning har en identitet, ett UUID och en lista över sekundära. När den aktiveras aktiverar hanteraren också dessa sekundära i ordning, och det är så en VPN följer ett Wi-Fi-nätverk utan ett manuellt klick. Relationen bor på basanslutningen, skriven som UUID-strängar i stället för namn. Det valet av representation är inte slumpmässigt; det är det som gör att kopplingen överlever ett namnbyte.

Den detaljen om namn betyder mer än den verkar. Att byta namn på en VPN-profil lämnar dess UUID orört, så befintliga kopplingar fortsätter att fungera. Att radera den gamla profilen och importera en ny ger ett nytt UUID, och varje koppling som pekade på den gamla pekar nu på ingenting.

Granska den befintliga listan innan du lägger till något. En hemmaprofil med en sekundär är inte en regel som passar varje SSID; det är en rad i ett objekt, och den kommer inte att konsulteras när en annan bas aktiveras.

Placera kopplingen där profilerna skapas

På en personlig dator, gör bifogandet av den avsedda sekundären till en del av att lägga till varje tillåten Wi-Fi-profil. Det är en vana snarare än en funktion, men en vana som ger ett konsekvent tillstånd, och det kostar ett kommando eller två dialogbesök per nätverk. Håll en kort anteckning om vilka nätverk som ska bära tunneln, eftersom listan är policyn.

På hanterade enheter, låt etableringsflödet skapa Wi-Fi-posten och dess VPN-koppling i samma steg, och tillämpa samma behandling på tillåtna profiler som redan finns. Att distribuera en VPN-profil ensam lämnar basrelationerna ospecificerade, och det är så en flotta hamnar med en tunnel som bara hälften av datorerna använder.

Där användare fortfarande kan skapa profiler utanför den hanterade vägen, bestäm uttryckligen vad som händer med dessa poster. Att anta att de ärver en koppling är inte en policy; det är ett hopp med en supportkostnad.

Planera för att VPN:ens identitet ändras

Etableringskällan behöver UUID:t för den avsedda VPN:en, inte ett visningsnamn som någon har gissat. När underhåll ersätter den VPN:en med ett nyimporterat objekt, uppdatera etableringsmallen och de berörda befintliga kopplingarna i samma ändring. Ett namnbyte är inte en ersättning, och att behandla de två som likvärdiga är hur en fungerande utrullning går sönder en vecka senare.

Förvara UUID:t bredvid anledningen till att det finns. En framtida ingenjör som hittar ett bart UUID i en lista över sekundära kan inte avgöra om det är aktuellt, och raderar det förmodligen när hen städar.

Aktivering är inte verkställighet

En begäran om sekundär sker vid aktiveringstillfället. Den blockerar inte program under intervallet innan autentiseringen är klar, och den stoppar inte trafik efter att tunneln misslyckas. Det är olika egenskaper som tillhandahålls av olika mekanismer, och att blanda ihop dem ger en design som ser strikt ut i profilen och är efterlåtande i praktiken.

Att blockera direkt trafik är en separat funktion med egen konfiguration och egna fellägen, och den måste ta hänsyn till trafiken som måste nå nätverket innan någon tunnel kan existera: captive-portaler, inloggningssidor, själva slutpunkten. En blockeringspolicy som inte kan uppfyllas före autentisering låser maskinen ute från just det nätverk den behöver.

Sätt in den skillnaden i instruktionerna som användarna faktiskt läser. Ett nytt Wi-Fi-nätverk kan begära tunneln; verkställigheten avgör om något får gå ut när den inte kan ansluta. Användare som bara får höra den första halvan kommer att rapportera designen som trasig.

Testa med en verkligt ny profil

Använd ett godkänt testnätverk och en nyupprättad basprofil, inte hemmaposten som redan fungerar. Observera basaktiveringen, det begärda sekundära UUID:t och eventuell autentiseringsprompt i följd, och notera vilket steg som fastnar när det fastnar. En hemlig agent som blir tillgänglig efter inloggning på skrivbordet finns inte automatiskt i varje startkontext, så en omstart hör till testplanen. Kontrollera sedan den avsedda resursen och felvegen: kommer tunneln upp innan programmet behöver den, och vad händer med det programmet när autentiseringen misslyckas?

Kontrollera sedan den avsedda resursen och felvegen: kommer tunneln upp innan programmet behöver den, och vad händer med det programmet när tunneln inte kan autentisera? De två observationerna är acceptanskriterierna, och ingen av dem syns i själva profilen.