Kan en enda VPN-tjänst täcka Windows-, Mac- och Linux-datorer?

Tre bärbara datorer i samma team, tre olika VPN-menyer och ett ärende som säger att anslutningen fungerar överallt utom på Macen. Planen bakom de klienterna kan vara identisk även när menyerna inte är det. Det som måste stämma är snävare än de flesta utrullningar antar: en gatewayidentitet, en typ av inloggningsuppgift, en uppsättning rutter och en resolverpolicy. Skriv ned de fyra innan någon exporterar en profil, och plattformsarbetet blir en checklista i stället för en utredning.

Börja med åtkomstkontraktet, inte med klientfilen

Åtkomstkontraktet är fem rader som en granskare kan kontrollera utan att öppna en leverantörskonsol. Det namnger de privata prefix som måste vara nåbara, de interna namn som måste slås upp, resolvern som svarar på dem, trafiken som får stanna på den lokala vägen och det gatewaycertifikat som klienten bör förvänta sig. Allt annat i utrullningen är en översättning av de raderna till ett filformat.

Ett kontorsexempel gör formen konkret: applikationsservrar i 10.60.0.0/16, privata namn under corp.example, en intern resolver på 10.61.0.53 och vanlig surfning kvar på den väg enheten redan använder. Den sista posten är ett policybeslut och inte en klientstandard, och flera klienter skickar allt genom tunneln om ingen säger annat. Dokumentera kontraktet med datum och ägare, för det är den dokumentationen som senare säger om det var tunneln eller policyn som ändrades.

Välj ett protokoll och ett autentiseringspar du kan försvara

IKEv2 med certifikatbaserad gatewayautentisering och EAP för användaren är det vanliga valet när alla tre plattformarna måste fungera utan extra programvara, eftersom Windows, macOS och NetworkManager alla levererar en IKEv2-klient. Problemet är att stöd för IKEv2 beskriver en etikett, inte en funktionsuppsättning. EAP-metoder, hårdvarustödda nycklar, mappning från certifikat till konto och automatisk återanslutning implementeras per plattform. En kombination som fungerar på två av tre är tillräckligt vanlig för att du bör utgå från den tills den är testad.

Testa paret på varje målplattform innan distributionsguiden skrivs, inte efter. En gateway som erbjuder både EAP-MSCHAPv2 och EAP-TLS ger utrymme för en reservväg, förutsatt att reservvägen är dokumenterad som stödd och inte upptäcks under en incident. Två stödda vägar är en billig försäkring; en odokumenterad tredje väg är ett framtida ärende.

När inget enskilt par täcker alla tre klienterna är de ärliga alternativen att lägga till en klient, lägga till en gatewayprofil eller begränsa listan över stödda plattformar. Att stänga av certifikatvalidering på den plattform som klagar högst är inte ett av dem. Den ändringen förvandlar en kompatibilitetslucka till en avlyssningsrisk, och inget senare steg i utrullningen reparerar den.

Bygg en artefakt per plattform utifrån kontraktet

Windows använder en VPNv2-profil, levererad via MDM eller skapad lokalt med Add-VpnConnection plus dess XML-nyttolast. Det som biter är omfång och förtroende. En profil med enhetsomfång och en med användaromfång installeras i olika arkiv, så certifikatet klienten behöver måste ligga i det arkiv som matchar det valda omfånget. Blir den kopplingen fel får du en profil som importeras rent och sedan misslyckas vid första anslutningen.

macOS använder en konfigurationsprofil med den hanterade VPN-nyttolasten, signerad och distribuerad via MDM eller installerad för hand i en pilot. Identiteten och CA-kedjan färdas som separata nyttolaster, och därför kan en profil installeras utan klagomål och ändå misslyckas vid anslutning. Kontrollera nyttolastlistan, inte bara installationsresultatet.

Linux beror på backend bakom NetworkManager, och strongSwan plus NetworkManager-pluginen är separata paket. Anslutningsegenskaperna är pluginspecifika och inte generiska VPN-nycklar, så en nyckel som kopierats från en annan plugin sparas ofta utan fel och misslyckas sedan vid aktivering. Bygg anslutningen på en ren image för att bekräfta att pluginen finns där den faktiskt ska köras.

De tre artefakterna skiljer sig i format, men var och en kodar samma fem kontraktsrader. Det är testet på om en artefakt är klar: varje rad finns representerad någonstans och inget extra har hittats på längs vägen.

Verifiera rutter, resolver och återanslutning på ett rent konto

Ansluten är inte acceptanstestet. På Windows visar Get-VpnConnection profilen och route print visar om det privata prefixet hamnade på tunnelgränssnittet. På macOS bekräftar scutil --nc list den aktiva tjänsten medan scutil --dns visar den resolverordning systemet verkligen kommer att använda.

På Linux bevisar nmcli connection show --active att anslutningen är uppe och resolvectl status visar DNS per länk. En resolver som finns i anslutningsfilen men saknas i utdata per länk betyder att delad DNS inte tillämpas. Det är skillnaden mellan namn som löses upp och namn som löses upp genom tunneln, och den avgör vilket supportteam som äger nästa steg. Jämför utdata per länk före och efter att anslutningen kommer upp, inte bara efter.

Kör hela kontrollen med ett nytt konto, utan cachade inloggningsuppgifter och utan certifikat installerat av administratören. Upprepa sedan efter viloläge och återupptagning, och en gång till efter att ha tvingat fram ny inmatning av uppgifterna. De två övergångarna avslöjar de flesta återanslutningsfel som en första anslutning aldrig visar.

Versionsmärk paketet och behåll en återställningsväg

Märk varje plattformspaket med den kontraktsrevision det implementerar och notera vilka klient- och gatewayversioner du godkände det mot. När beteendet ändras efter en klientuppdatering pekar märkningen på ett kontrakt att testa om i stället för en fil att gissa på.

Håll föregående paket för varje plattform åtkomligt och skriv dess borttagningskommando bredvid. Att avinstallera en VPN-profil är inte spegelbilden av att installera den på Windows, macOS eller Linux, och skillnaderna visar sig vid sämsta möjliga tillfälle. Repetera borttagningen en gång på en reservenhet så att arkivet blir en plan i stället för en förhoppning.