Kan één VPN-dienst Windows-, Mac- en Linux-desktops dekken?
Eén toegangsplan kan Windows-, Mac- en Linux-desktops bedienen, maar pas nadat gateway-identiteit, inloggegevens, routes en resolverbeleid vastliggen.
Drie laptops in één team, drie verschillende VPN-menu's en een ticket dat zegt dat de verbinding overal werkt behalve op de Mac. Het plan achter die clients kan identiek zijn, ook als de menu's dat niet zijn. Wat op één lijn moet staan, is smaller dan de meeste uitrollen aannemen: één gateway-identiteit, één type inloggegevens, één set routes en één resolverbeleid. Schrijf die vier op voordat iemand een profiel exporteert, en het platformwerk wordt een checklist in plaats van een onderzoek.
Begin bij het toegangscontract, niet bij het clientbestand
Het toegangscontract bestaat uit vijf regels die een reviewer kan controleren zonder de console van een leverancier te openen. Het benoemt de privéprefixen die bereikbaar moeten zijn, de interne namen die moeten resolveren, de resolver die ze beantwoordt, het verkeer dat op het lokale pad mag blijven en het gatewaycertificaat dat de client hoort te zien. Al het overige in de uitrol is een vertaling van die regels naar een bestandsformaat.
Een voorbeeld van een kantoor maakt de vorm concreet: applicatieservers in 10.60.0.0/16, privénamen onder corp.example, een interne resolver op 10.61.0.53 en gewoon browsen op het pad dat het apparaat al gebruikt. Dat laatste punt is een beleidsbeslissing en geen clientstandaard, en meerdere clients sturen alles door de tunnel als niemand iets anders zegt. Leg het contract vast met een datum en een eigenaar, want juist dat vastleggen vertelt je later of de tunnel is veranderd of het beleid.
Kies één protocol en één authenticatiepaar dat je kunt verdedigen
IKEv2 met certificaatgebaseerde gatewayauthenticatie en EAP voor de gebruiker is de gebruikelijke keuze wanneer alle drie de platforms zonder extra software moeten werken, omdat Windows, macOS en NetworkManager elk een IKEv2-client meeleveren. Het probleem is dat IKEv2 ondersteunen een label beschrijft, geen functieset. EAP-methoden, hardware-ondersteunde sleutels, certificaat-naar-account-mapping en automatisch opnieuw verbinden zijn per platform geïmplementeerd. Een combinatie die op twee van de drie werkt, komt zo vaak voor dat je die moet aannemen tot je hem hebt getest.
Test het paar op elk doelplatform voordat de implementatiehandleiding wordt geschreven, niet erna. Een gateway die zowel EAP-MSCHAPv2 als EAP-TLS biedt, geeft ruimte voor een terugvalpad, mits dat terugvalpad als ondersteund is gedocumenteerd en niet tijdens een incident wordt ontdekt. Twee ondersteunde paden zijn een goedkope verzekering; een ongedocumenteerd derde pad is een toekomstig ticket.
Als geen enkel paar alle drie de clients dekt, zijn de eerlijke opties een client toevoegen, een gatewayprofiel toevoegen of de lijst met ondersteunde platforms verkleinen. Certificaatvalidatie uitzetten op het platform dat het luidst klaagt, hoort daar niet bij. Die wijziging maakt van een compatibiliteitskloof een onderscheppingsrisico, en geen latere stap in de uitrol herstelt dat.
Bouw één artefact per platform op basis van het contract
Windows gebruikt een VPNv2-profiel, geleverd via MDM of lokaal gemaakt met Add-VpnConnection plus de bijbehorende XML-payload. De lastige delen zijn scope en vertrouwen. Een profiel met apparaatbereik en een met gebruikersbereik worden in verschillende opslagplaatsen geïnstalleerd, dus het certificaat dat de client nodig heeft, moet in de opslag staan die bij de gekozen scope past. Die combinatie verkeerd krijgen levert een profiel op dat netjes importeert en vervolgens bij de eerste verbinding faalt.
macOS gebruikt een configuratieprofiel met de beheerde VPN-payload, ondertekend en via MDM verspreid of voor een pilot met de hand geïnstalleerd. De identiteit en de CA-keten reizen als afzonderlijke payloads, en daarom kan een profiel zonder klachten installeren en toch op het moment van verbinden falen. Controleer de payloadlijst, niet alleen het installatieresultaat.
Linux hangt af van de backend achter NetworkManager, en strongSwan plus de NetworkManager-plugin zijn afzonderlijke pakketten. Verbindingseigenschappen zijn pluginspecifiek en geen generieke VPN-sleutels, dus een sleutel die uit een andere plugin is gekopieerd, slaat vaak zonder fout op en faalt dan bij het activeren. Bouw de verbinding op een schone image om te bevestigen dat de plugin aanwezig is waar hij echt gaat draaien.
De drie artefacten verschillen in formaat, maar elk codeert dezelfde vijf contractregels. Dat is de test of een artefact af is: elke regel is ergens vertegenwoordigd en er is onderweg niets extras verzonnen.
| Platform | Artifact | Check before handoff |
|---|---|---|
| Windows | VPNv2 profile or Add-VpnConnection | Scope matches certificate store |
| macOS | Managed VPN payload plus certificate payload | Both payloads present in one profile |
| Linux | NetworkManager connection with strongSwan backend | Plugin package installed on the image |
Controleer routes, resolver en herverbinding op een schoon account
Verbonden is niet de acceptatietest. Op Windows toont Get-VpnConnection het profiel en laat route print zien of het privéprefix op de tunnelinterface is beland. Op macOS bevestigt scutil --nc list de actieve service terwijl scutil --dns de resolvervolgorde toont die het systeem echt gaat gebruiken.
Op Linux bewijst nmcli connection show --active dat de verbinding actief is en toont resolvectl status DNS per link. Een resolver die wel in het verbindingsbestand staat maar ontbreekt in de uitvoer per link, betekent dat split-DNS niet wordt toegepast. Dat is het verschil tussen namen die resolveren en namen die via de tunnel resolveren, en het verandert welk supportteam de volgende stap heeft. Vergelijk de uitvoer per link voor en na het opkomen van de verbinding, niet alleen erna.
Voer de hele controle uit met een vers account, zonder gecachte inloggegevens en zonder door de beheerder geïnstalleerd certificaat. Herhaal het daarna na een suspend en resume, en nog eens nadat je opnieuw invoeren van inloggegevens hebt afgedwongen. Die twee overgangen brengen de meeste herverbindingsfouten aan het licht die een eerste verbinding nooit laat zien.
Geef het pakket een versie en houd een rollbackpad achter de hand
Voorzie elk platformpakket van de contractrevisie die het implementeert, en noteer de client- en gatewayversies waarmee je het hebt geaccepteerd. Als het gedrag na een clientupdate verandert, wijst de tag naar een contract om opnieuw te testen in plaats van een bestand om naar te raden.
Houd het vorige pakket per platform vindbaar en schrijf de verwijderopdracht ernaast. Een VPN-profiel verwijderen is op Windows, macOS en Linux geen spiegelbeeld van het installeren, en de verschillen komen op het slechtste moment naar boven. Oefen het verwijderen één keer op een reservetoestel, zodat het archief een plan wordt in plaats van hoop.