Kan een VPN-diens Windows-, Mac- en Linux-rekenaars dek?
Een toegangsplan kan Windows-, Mac- en Linux-rekenaars bedien, maar eers nadat die gateway-identiteit, die geloofsbrief, die roetes en die resolver-beleid vasgestel is.
Drie skootrekenaars in een span, drie verskillende VPN-kieslyste, en ’n kaartjie wat sê die verbinding werk oral behalwe op die Mac. Die plan agter daardie kliënte kan identies wees selfs wanneer die kieslyste dit nie is. Wat moet klop, is smaller as wat die meeste ontplooiings aanvaar: een gateway-identiteit, een tipe geloofsbrief, een stel roetes en een resolver-beleid. Skryf daardie vier neer voordat iemand ’n profiel uitvoer, en die platformwerk word ’n kontrolelys in plaas van ’n ondersoek.
Begin met die toegangskontrak, nie die kliëntlêer nie
Die toegangskontrak is vyf reëls wat ’n keurder kan nagaan sonder om ’n verskafferkonsole oop te maak. Dit noem die private voorvoegsels wat bereikbaar moet wees, die interne name wat moet resolve, die resolver wat hulle beantwoord, die verkeer wat op die plaaslike pad mag bly, en die gateway-sertifikaat wat die kliënt moet verwag om te sien. Alles anders in die ontplooiing is ’n vertaling van daardie reëls in ’n lêerformaat.
’n Kantoorvoorbeeld maak die vorm konkreet: toepassingbedieners in 10.60.0.0/16, private name onder corp.example, ’n interne resolver by 10.61.0.53, en gewone blaaiery wat op watter pad die toestel ook al gebruik, gelaat word. Daardie laaste item is ’n beleidsbesluit eerder as ’n kliëntverstek, en verskeie kliënte sal alles deur die tonnel stuur as niemand anders sê nie. Teken die kontrak aan met ’n datum en ’n eienaar, want daardie rekord is wat jou later vertel of die tonnel verander het of die beleid.
Kies een protokol en een aanmeldingspaar wat jy kan verdedig
IKEv2 met sertifikaatgebaseerde gateway-verifikasie en EAP vir die gebruiker is die gewone keuse wanneer al drie platforms sonder bykomende sagteware moet werk, aangesien Windows, macOS en NetworkManager elk ’n IKEv2-kliënt lewer. Die probleem is dat die ondersteuning van IKEv2 ’n etiket beskryf, nie ’n funksiestel nie. EAP-metodes, hardeware-gesteunde sleutels, sertifikaat-tot-rekening-kartering en outomatiese herverbinding word per platform geïmplementeer. ’n Kombinasie wat op twee van die drie werk, is algemeen genoeg dat jy dit moet aanneem tot dit getoets is.
Toets die paar op elke teikenplatform voordat die ontplooiingsgids geskryf word, nie daarna nie. ’n Gateway wat beide EAP-MSCHAPv2 en EAP-TLS bied, gee jou ruimte om terug te val, mits die terugval as ondersteun gedokumenteer is eerder as tydens ’n insident ontdek word. Twee ondersteunde paaie is goedkoop versekering; ’n ongedokumenteerde derde pad is ’n toekomstige kaartjie.
Wanneer geen enkele paar al drie kliënte dek nie, is die eerlike opsies om ’n kliënt by te voeg, ’n gateway-profiel by te voeg, of die lys ondersteunde platforms te vernou. Om sertifikaatvalidering af te skakel op die platform wat die hardste kla, is nie een daarvan nie. Daardie verandering omskep ’n versoenbaarheidsgaping in ’n onderskeppingsrisiko, en geen later stap in die ontplooiing herstel dit nie.
Bou een artefak per platform uit die kontrak
Windows neem ’n VPNv2-profiel, gelewer deur MDM of plaaslik geskep met Add-VpnConnection plus sy XML-lading. Die dele wat byt, is omvang en vertroue. ’n Toestelgerigte profiel en ’n gebruiker-gerigte profiel installeer in verskillende store, so die sertifikaat wat die kliënt nodig het, moet in die store sit wat by die omvang pas wat jy gekies het. Om daardie paring verkeerd te kry, lewer ’n profiel wat skoon invoer en dan by die eerste verbinding misluk.
macOS neem ’n konfigurasieprofiel met die bestuurde VPN-lading, onderteken en deur MDM gestuur of met die hand geïnstalleer vir ’n loodsprojek. Die identiteit en die CA-ketting reis as aparte ladings, en daarom kan ’n profiel sonder klagte installeer en steeds by verbindingstyd misluk. Kontroleer die ladinglys, nie net die installasieresultaat nie.
Linux hang af van die backend agter NetworkManager, en strongSwan plus die NetworkManager-inprop is aparte pakkette. Verbindingeienskappe is inprop-spesifiek eerder as algemene VPN-sleutels, so ’n sleutel wat uit ’n ander inprop gekopieer is, stoor dikwels sonder fout en misluk dan by aktivering. Bou die verbinding op ’n skoon beeld om te bevestig dat die inprop daar is waar dit werklik sal loop.
Die drie artefakte verskil in formaat, maar elkeen kodeer dieselfde vyf kontrakreëls. Dit is die toets of ’n artefak klaar is: elke reël word êrens verteenwoordig, en niks ekstra is langs die pad uitgedink nie.
| 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 |
Verifieer roetes, resolver en herverbinding op ’n skoon rekening
Gekoppel is nie die aanvaardingstoets nie. Op Windows wys Get-VpnConnection die profiel en route print wys of die private voorvoegsel op die tonnelkoppelvlak beland het. Op macOS bevestig scutil --nc list die aktiewe diens terwyl scutil --dns die resolver-orde wys wat die stelsel werklik sal gebruik.
Op Linux bewys nmcli connection show --active dat die verbinding op is en resolvectl status wys DNS per skakel. ’n Resolver wat in die verbindingslêer voorkom maar in die per-skakel-uitset ontbreek, beteken dat gesplete DNS nie toegepas word nie. Dit is die verskil tussen name wat resolve en name wat deur die tonnel resolve, en dit verander watter ondersteuningspan die volgende stap besit. Vergelyk die per-skakel-uitset voor en nadat die verbinding opkom, nie net daarna nie.
Voer die hele kontrole uit as ’n vars rekening met geen gekapte geloofsbriewe en geen sertifikaat wat deur ’n administrateur geïnstalleer is nie. Herhaal dit dan ná ’n slaap en hervat, en nog een keer nadat jy ’n hertoevoer van geloofsbriewe geforseer het. Daardie twee oorgange bring die meeste herverbindingsfoute na vore wat ’n eerste verbinding nooit wys nie.
Bewaar weergawes van die pakket en hou ’n terugrolpad
Merk elke platformpakket met die kontrakweergawe wat dit implementeer, en noteer die kliënt- en gateway-weergawes waarteen jy dit aanvaar het. Wanneer gedrag ná ’n kliëntopdatering verander, wys die merker na ’n kontrak om te hertoets eerder as na ’n lêer om te raai.
Hou die vorige pakket vir elke platform beskikbaar, en skryf sy verwyderingsopdrag daarby. Om ’n VPN-profiel te deïnstalleer is nie die spieëlbeeld van die installering daarvan op Windows, macOS of Linux nie, en die verskille wys op die slegste moontlike tyd. Oefen die verwydering een keer op ’n ekstra toestel sodat die argief ’n plan word eerder as ’n hoop.