Een secundaire VPN hoort bij één Wi-Fi-profiel, niet bij alle

Configureer een VPN als secundaire van de thuis-Wi-Fi-verbinding en alles werkt, totdat de laptop verbinding maakt met een ander toegangspunt en de tunnel omlaag blijft. De nieuwe verbinding is een apart configuratieobject met zijn eigen UUID, en het heeft geen enkele reden om de band te kennen die u voor zijn voorganger hebt gemaakt. Niets was defect; de associatie heeft simpelweg nooit bestaan.

De verbindingsreferentie van NetworkManager definieert secundairen als UUID's die samen met een bepaalde basisverbinding worden geactiveerd. Er staat ook in dat gewone VPN-profielen geen automatische activering implementeren zoals basisverbindingen dat doen. Beide uitspraken leiden tot dezelfde conclusie: de associatie is per profiel, en iemand moet die voor elk nieuw profiel aanmaken.

Wat een secundaire feitelijk is

Een basisverbinding heeft een identiteit, een UUID en een lijst met secundairen. Wanneer die wordt geactiveerd, activeert de beheerder ook die secundairen in volgorde, en zo volgt een VPN een Wi-Fi-netwerk zonder handmatige klik. De relatie staat op de basisverbinding, geschreven als UUID-strings in plaats van namen. Die keuze van weergave is niet toevallig; juist daardoor overleeft de associatie een naamsverandering.

Dat detail over namen is belangrijker dan het lijkt. Het hernoemen van een VPN-profiel laat zijn UUID ongemoeid, zodat bestaande associaties blijven werken. Het verwijderen van het oude profiel en het importeren van een nieuw levert een nieuwe UUID op, en elke associatie die naar de oude verwees, verwijst nu naar niets.

Controleer de bestaande lijst voordat u iets toevoegt. Een thuisprofiel met één secundaire is geen regel die op elk SSID past; het is één rij in één object, en er wordt niet naar gekeken wanneer een andere basis wordt geactiveerd.

Plaats de associatie waar profielen worden aangemaakt

Maak op een persoonlijke machine van het koppelen van de bedoelde secundaire een onderdeel van het toevoegen van elk toegestaan Wi-Fi-profiel. Het is een gewoonte in plaats van een functie, maar een gewoonte die een consistente toestand oplevert, en het kost één opdracht of twee dialoogbezoeken per netwerk. Houd een korte notitie bij van welke netwerken de tunnel moeten dragen, want de lijst is het beleid.

Laat op beheerde apparaten de inrichtingsworkflow het Wi-Fi-item en de bijbehorende VPN-associatie in dezelfde stap aanmaken, en pas dezelfde behandeling toe op toegestane profielen die al bestaan. Alleen een VPN-profiel distribueren laat de basisrelaties ongespecificeerd, en zo krijgt een vloot een tunnel die slechts de helft van de laptops gebruikt.

Waar gebruikers nog profielen kunnen aanmaken buiten het beheerde pad, beslist u expliciet wat er met die items gebeurt. Aannemen dat ze een associatie erven is geen beleid; het is een hoop met bijbehorende ondersteuningskosten.

Plan voor het veranderen van de identiteit van de VPN

De inrichtingsbron heeft de UUID van de bedoelde VPN nodig, niet een weergavenaam die iemand heeft geraden. Wanneer onderhoud die VPN vervangt door een vers geïmporteerd object, werkt u de inrichtingssjabloon en de betrokken bestaande associaties in dezelfde wijziging bij. Een naamsverandering is geen vervanging, en beide als gelijkwaardig behandelen is hoe een werkende uitrol een week later breekt.

Bewaar de UUID naast de reden waarom die bestaat. Een toekomstige ingenieur die een kale UUID in een lijst met secundairen vindt, kan niet zien of die actueel is, en zal die waarschijnlijk verwijderen tijdens het opruimen.

Activering is geen handhaving

Een verzoek voor een secundaire gebeurt op het moment van activering. Het blokkeert applicaties niet in het interval voordat de verificatie is voltooid, en het stopt geen verkeer nadat de tunnel faalt. Dat zijn verschillende eigenschappen die door verschillende mechanismen worden geleverd, en ze verwarren levert een ontwerp op dat er in het profiel streng uitziet en in de praktijk toegeeflijk is.

Het blokkeren van direct verkeer is een aparte functie met een eigen configuratie en eigen faalmodi, en er moet rekening worden gehouden met het verkeer dat het netwerk moet bereiken voordat er ooit een tunnel kan bestaan: captive portals, inlogpagina's, het eindpunt zelf. Een blokkeerbeleid dat niet kan worden vervuld voordat de verificatie is voltooid, sluit de machine buiten juist het netwerk dat ze nodig heeft.

Zet dat onderscheid in de instructies die gebruikers daadwerkelijk lezen. Een nieuw Wi-Fi-netwerk kan om de tunnel vragen; handhaving bepaalt of er iets naar buiten mag wanneer er geen verbinding mogelijk is. Gebruikers die alleen de eerste helft te horen krijgen, zullen het ontwerp als defect melden.

Test met een werkelijk nieuw profiel

Gebruik een goedgekeurd testnetwerk en een nieuw aangemaakt basisprofiel, niet het thuisitem dat al werkt. Observeer de activering van de basis, de gevraagde secundaire UUID en elke verificatieprompt op volgorde, en noteer welke fase vastloopt wanneer die vastloopt. Een geheime agent die na de desktopaanmelding beschikbaar komt, is niet automatisch in elke opstartcontext aanwezig, dus een herstart hoort in het testplan. Controleer vervolgens de beoogde bron en het faalpad: komt de tunnel omhoog voordat de applicatie die nodig heeft, en wat gebeurt er met die applicatie wanneer de verificatie mislukt?

Controleer vervolgens de beoogde bron en het faalpad: komt de tunnel omhoog voordat de applicatie die nodig heeft, en wat gebeurt er met die applicatie wanneer de tunnel zich niet kan verifiëren? Die twee observaties zijn de acceptatiecriteria, en geen van beide is zichtbaar in het profiel zelf.