Kan éin einaste VPN-teneste dekkje Windows-, Mac- og Linux-datamaskiner?

Tre berbare maskiner i same teamet, tre ulike VPN-menyar og ein sak som seier at sambandet virkar overalt utanom på Macen. Planen bak desse klientane kan vere identisk sjølv når menyane ikkje er det. Det som må stemme er trongare enn dei fleste utrullingar føreset: éin gatewayidentitet, éin type påloggingsinformasjon, eitt sett ruter og éin resolverpolicy. Skriv ned dei fire før nokon eksporterer ein profil, og plattformarbeidet blir ei sjekkliste i staden for ei etterforsking.

Start med tilgangskontrakten, ikkje klientfila

Tilgangskontrakten er fem liner som ein gjennomlesar kan kontrollere utan å opne ein leverandørkonsoll. Han nemner dei private prefiksa som må vere nåbare, dei interne namna som må slåast opp, resolveren som svarar på dei, trafikken som får bli på den lokale vegen og gateway-sertifikatet klienten bør vente å sjå. Alt anna i utrullinga er ei omsetjing av desse linene til eit filformat.

Eit kontoreksempel gjer forma konkret: applikasjonsservarar i 10.60.0.0/16, private namn under corp.example, ein intern resolver på 10.61.0.53 og vanleg nettsurfing att på vegen eininga allereie brukar. Det siste punktet er ei policyavgjerd og ikkje ein klientstandard, og fleire klientar sender alt gjennom tunnelen om ingen seier noko anna. Registrer kontrakten med dato og eigar, for det er den registreringa som seinare fortel om det var tunnelen eller policyen som endra seg.

Vel éin protokoll og eitt autentiseringspar du kan forsvare

IKEv2 med sertifikatbasert gateway-autentisering og EAP for brukaren er det vanlege valet når alle tre plattformane må verke utan ekstra programvare, sidan Windows, macOS og NetworkManager alle leverer ein IKEv2-klient. Problemet er at støtte for IKEv2 skildrar ein etikett, ikkje eit funksjonssett. EAP-metodar, maskinvarestøtta nøklar, tilordning frå sertifikat til konto og automatisk gjenoppkopling blir implementerte per plattform. Ein kombinasjon som verkar på to av tre er vanleg nok til at du bør rekne med det til han er testa.

Test paret på kvar målplattform før distribusjonsrettleiinga blir skriven, ikkje etterpå. Ein gateway som tilbyr både EAP-MSCHAPv2 og EAP-TLS gir rom for ein reserveveg, føresett at reservevegen er dokumentert som støtta og ikkje oppdaga under ei hending. To støtta vegar er billeg forsikring; ein udokumentert tredje veg er ein framtidig sak.

Når ingen einskild par dekkjer alle tre klientane, er dei ærlege alternativa å leggje til ein klient, leggje til ein gatewayprofil eller snevre inn lista over støtta plattformar. Å slå av sertifikatvalidering på plattformen som klagar høgast er ikkje eitt av dei. Den endringa gjer eit kompatibilitetsgap om til ein avlyttingsrisiko, og ingen seinare del av utrullinga reparerer han.

Bygg éin artefakt per plattform frå kontrakten

Windows brukar ein VPNv2-profil, levert via MDM eller oppretta lokalt med Add-VpnConnection pluss XML-nyttelasta. Det som bit er omfang og tillit. Ein profil med einingomfang og ein med brukaromfang blir installerte i ulike lager, så sertifikatet klienten treng må liggje i lageret som svarar til omfanget du valde. Blir denne koplinga feil, får du ein profil som blir importert reint og deretter feilar ved første tilkopling.

macOS brukar ein konfigurasjonsprofil med den administrerte VPN-nyttelasta, signert og distribuert via MDM eller installert manuelt for ein pilot. Identiteten og CA-kjeda reiser som separate nyttelaster, og difor kan ein profil bli installert utan klagar og likevel feile ved tilkopling. Kontroller nyttelastlista, ikkje berre installasjonsresultatet.

Linux er avhengig av backenden bak NetworkManager, og strongSwan pluss NetworkManager-pluginen er separate pakkar. Tilkoplingseigenskapane er pluginspesifikke og ikkje generiske VPN-nøklar, så ein nøkkel kopiert frå ein annan plugin blir ofte lagra utan feil og feilar deretter ved aktivering. Bygg tilkoplinga på eit reint image for å stadfeste at pluginen finst der han faktisk skal køyre.

Dei tre artefaktane skil seg i format, men kvar av dei kodar dei same fem kontraktslinene. Det er testen på om ein artefakt er ferdig: kvar line er representert ein stad, og ingenting ekstra er funne opp undervegs.

Verifiser ruter, resolver og gjenoppkopling på ein rein konto

Tilkopla er ikkje akseptansetesten. På Windows viser Get-VpnConnection profilen og route print viser om det private prefikset hamna på tunellgrensesnittet. På macOS stadfester scutil --nc list den aktive tenesta medan scutil --dns viser resolverrekkjefølgja systemet faktisk vil bruke.

På Linux beviser nmcli connection show --active at tilkoplinga er oppe og resolvectl status viser DNS per lenkje. Ein resolver som finst i tilkoplinga men manglar i utdataa per lenkje, betyr at delt DNS ikkje blir brukt. Det er skilnaden mellom namn som blir løyste og namn som blir løyste gjennom tunnelen, og han avgjer kva supportteam som eig neste steg. Samanlikn utdataa per lenkje før og etter at tilkoplinga kjem opp, ikkje berre etter.

Køyr heile kontrollen med ein ny konto, utan bufra påloggingsdata og utan sertifikat installert av administrator. Gjenta han deretter etter dvale og gjenopptaking, og ein gong til etter å ha tvinga fram ny inntasting av påloggingsdata. Dei to overgangane avdekkjer dei fleste feila ved gjenoppkopling som ei første tilkopling aldri viser.

Versjoner pakken og hald ein tilbakerullingsveg

Merk kvar plattformpakke med kontraktsrevisjonen han implementerer, og noter kva klient- og gatewayversjonar du godkjende han mot. Når åtferda endrar seg etter ein klientoppdatering, peikar merket på ein kontrakt som skal testast på nytt i staden for ei fil å gjete på.

Hald førre pakke for kvar plattform tilgjengeleg og skriv fjerningskommandoen ved sida av. Å avinstallere ein VPN-profil er ikkje spegelbildet av å installere han på Windows, macOS eller Linux, og skilnadene dukkar opp på verste moglege tidspunkt. Øv på fjerninga éin gong på ei reserveeining, slik at arkivet blir ein plan og ikkje eit håp.