Kan én enkelt VPN-tjeneste dekke Windows-, Mac- og Linux-datamaskiner?

Tre bærbare maskiner i samme team, tre ulike VPN-menyzer og en sak som sier at forbindelsen virker overalt unntatt på Macen. Planen bak disse klientene kan være identisk selv når menyene ikke er det. Det som må stemme er smalere enn de fleste utrullinger antar: én gatewayidentitet, én type påloggingsinformasjon, ett sett ruter og én resolverpolicy. Skriv ned de fire før noen eksporterer en profil, og plattformarbeidet blir en sjekkliste i stedet for en etterforskning.

Start med tilgangskontrakten, ikke klientfilen

Tilgangskontrakten er fem linjer som en gjennomleser kan kontrollere uten å åpne en leverandørkonsoll. Den navngir de private prefiksene som må være nåbare, de interne navnene som må slås opp, resolveren som svarer på dem, trafikken som får bli på den lokale veien og gateway-sertifikatet klienten bør forvente å se. Alt annet i utrullingen er en oversettelse av disse linjene til et filformat.

Et kontoreksempel gjør formen konkret: applikasjonsservere i 10.60.0.0/16, private navn under corp.example, en intern resolver på 10.61.0.53 og vanlig nettsurfing igjen på den veien enheten allerede bruker. Det siste punktet er en policybeslutning og ikke en klientstandard, og flere klienter sender alt gjennom tunnelen hvis ingen sier noe annet. Registrer kontrakten med dato og eier, for det er den registreringen som senere forteller om det var tunnelen eller policyen som endret seg.

Velg én protokoll og ett autentiseringspar du kan forsvare

IKEv2 med sertifikatbasert gateway-autentisering og EAP for brukeren er det vanlige valget når alle tre plattformene må virke uten ekstra programvare, siden Windows, macOS og NetworkManager alle leverer en IKEv2-klient. Problemet er at støtte for IKEv2 beskriver en etikett, ikke et funksjonssett. EAP-metoder, maskinvarestøttede nøkler, tilordning fra sertifikat til konto og automatisk gjenoppkobling implementeres per plattform. En kombinasjon som virker på to av tre er vanlig nok til at du bør anta det til den er testet.

Test paret på hver målplattform før distribusjonsveiledningen skrives, ikke etterpå. En gateway som tilbyr både EAP-MSCHAPv2 og EAP-TLS gir rom for en reservevei, forutsatt at reserveveien er dokumentert som støttet og ikke oppdaget under en hendelse. To støttede veier er billig forsikring; en udokumentert tredje vei er en fremtidig sak.

Når ingen enkelt par dekker alle tre klientene, er de ærlige alternativene å legge til en klient, legge til en gatewayprofil eller snevre inn listen over støttede plattformer. Å slå av sertifikatvalidering på plattformen som klager høyest er ikke ett av dem. Den endringen gjør et kompatibilitetsgap om til en avlyttingsrisiko, og ingen senere del av utrullingen reparerer den.

Bygg én artefakt per plattform fra kontrakten

Windows bruker en VPNv2-profil, levert via MDM eller opprettet lokalt med Add-VpnConnection pluss XML-nyttelasten. Det som biter er omfang og tillit. En profil med enhetsomfang og en med brukeromfang installeres i ulike lagre, så sertifikatet klienten trenger må ligge i lagret som samsvarer med omfanget du valgte. Blir denne koblingen feil, får du en profil som importeres rent og deretter feiler ved første tilkobling.

macOS bruker en konfigurasjonsprofil med den administrerte VPN-nyttelasten, signert og distribuert via MDM eller installert manuelt for en pilot. Identiteten og CA-kjeden reiser som separate nyttelaster, og derfor kan en profil installeres uten klager og likevel feile ved tilkobling. Kontroller nyttelastlisten, ikke bare installasjonsresultatet.

Linux avhenger av backenden bak NetworkManager, og strongSwan pluss NetworkManager-pluginen er separate pakker. Tilkoblingsegenskapene er pluginspesifikke og ikke generiske VPN-nøkler, så en nøkkel kopiert fra en annen plugin lagres ofte uten feil og feiler deretter ved aktivering. Bygg tilkoblingen på et rent image for å bekrefte at pluginen finnes der den faktisk skal kjøre.

De tre artefaktene skiller seg i format, men hver av dem koder de samme fem kontraktslinjene. Det er testen på om en artefakt er ferdig: hver linje er representert et sted, og ingenting ekstra er funnet opp underveis.

Verifiser ruter, resolver og gjenoppkobling på en ren konto

Tilkoblet er ikke akseptansetesten. På Windows viser Get-VpnConnection profilen og route print viser om det private prefikset havnet på tunellgrensesnittet. På macOS bekrefter scutil --nc list den aktive tjenesten mens scutil --dns viser resolverrekkefølgen systemet faktisk vil bruke.

På Linux beviser nmcli connection show --active at tilkoblingen er oppe og resolvectl status viser DNS per lenke. En resolver som finnes i tilkoblingsfilen men mangler i utdataene per lenke, betyr at delt DNS ikke brukes. Det er forskjellen mellom navn som løses opp og navn som løses opp gjennom tunnelen, og den avgjør hvilket supportteam som eier neste steg. Sammenlign utdataene per lenke før og etter at tilkoblingen kommer opp, ikke bare etter.

Kjør hele kontrollen med en ny konto, uten bufrede påloggingsdata og uten sertifikat installert av administrator. Gjenta den deretter etter dvale og gjenopptakelse, og en gang til etter å ha tvunget frem ny inntasting av påloggingsdata. De to overgangene avdekker de fleste gjenoppkoblingsfeilene som en første tilkobling aldri viser.

Versjoner pakken og behold en tilbakerullingsvei

Merk hver plattformpakke med kontraktsrevisjonen den implementerer, og noter hvilke klient- og gatewayversjoner du godkjente den mot. Når atferden endres etter en klientoppdatering, peker merket på en kontrakt som skal testes på nytt i stedet for en fil å gjette på.

Hold forrige pakke for hver plattform tilgjengelig og skriv fjerningskommandoen ved siden av. Å avinstallere en VPN-profil er ikke speilbildet av å installere den på Windows, macOS eller Linux, og forskjellene dukker opp på verste mulige tidspunkt. Øv på fjerningen én gang på en reserveenhet, slik at arkivet blir en plan og ikke et håp.