Ĉu unu VPN-servo povas kovri Windows, Mac kaj Linux labortablojn?

Tri tekkomputiloj en unu teamo, tri malsamaj VPN-menuoj, kaj bileto kiu diras, ke la konekto funkcias ĉie krom sur la Mac. La plano malantaŭ tiuj klientoj povas esti identa eĉ kiam la menuoj ne estas. Tio, kio devas kongrui, estas pli mallarĝa ol plej multaj enkondukoj supozas: unu enireja identeco, unu akreditaĵa tipo, unu itinara aro kaj unu solvila politiko. Skribu tiujn kvar antaŭ ol iu eksportas profilon, kaj la platforma laboro fariĝas kontrol-liston anstataŭ enketo.

Komencu per la alirkontrakto, ne per la klienta dosiero

La alirkontrakto estas kvin linioj, kiujn recenzanto povas kontroli sen malfermi vendistan konzolon. Ĝi nomas la privatajn prefiksojn, kiuj devas esti atingeblaj, la internajn nomojn, kiuj devas esti solvitaj, la solvilon, kiu respondas pri ili, la trafikon, kiu rajtas resti sur la loka vojo, kaj la enirejan atestilon, kiun la kliento atendu vidi. Ĉio alia en la enkonduko estas traduko de tiuj linioj en dosierformon.

Oficeja ekzemplo faras la formon konkreta: aplikaj serviloj en 10.60.0.0/16, privataj nomoj sub corp.example, interna solvilo ĉe 10.61.0.53, kaj ordinara retumado lasita sur kiu ajn vojo la aparato jam uzas. La lasta ero estas politika decido, ne klienta defaŭlto, kaj pluraj klientoj sendos ĉion tra la tunelo se neniu diras alie. Registru la kontrakton kun dato kaj posedanto, ĉar tiu registro estas tio, kio poste diras al vi, ĉu la tunelo ŝanĝiĝis aŭ la politiko.

Elektu unu protokolon kaj unu aŭtentikigan paron, kiun vi povas defendi

IKEv2 kun atestila enireja aŭtentikigo kaj EAP por la uzanto estas la kutima elekto, kiam ĉiuj tri platformoj devas funkcii sen aldona programo, ĉar Windows, macOS kaj NetworkManager ĉiu liveras IKEv2-klienton. La problemo estas, ke subteni IKEv2 priskribas etikedon, ne funkciaron. EAP-metodoj, aparate subtenataj ŝlosiloj, mapado de atestilo al konto kaj aŭtomata rekonekto estas realigitaj po platformo. Kombino, kiu funkcias sur du el la tri, estas sufiĉe ofta por ke vi supozu ĝin ĝis ĝi estos testita.

Testu la paron sur ĉiu cela platformo antaŭ ol la enkonduka gvidilo estos skribita, ne poste. Enirejo, kiu proponas kaj EAP-MSCHAPv2 kaj EAP-TLS, donas al vi spacon por retroiri, kondiĉe ke la retroiro estas dokumentita kiel subtenata kaj ne malkovrita dum okazaĵo. Du subtenataj vojoj estas malmultekosta asekuro; nedokumentita tria vojo estas estonta bileto.

Kiam neniu paro kovras ĉiujn tri klientojn, la honestaj opcioj estas aldoni klienton, aldoni enirejan profilon aŭ mallarĝigi la liston de subtenataj platformoj. Malŝalti atestilan validigon sur la platformo, kiu plej laŭte plendas, ne estas unu el ili. Tiu ŝanĝo transformas kongruecan breĉon en riskon de interkapto, kaj neniu posta paŝo de la enkonduko riparas ĝin.

Konstruu unu artefakton po platformo el la kontrakto

Windows prenas VPNv2-profilon, liveritan de MDM aŭ kreitan loke per Add-VpnConnection kaj ĝia XML-ŝarĝo. La partoj, kiuj doloras, estas amplekso kaj fido. Aparatampleksa profilo kaj uzantampleksa profilo instaliĝas en malsamajn konservejojn, do la atestilo, kiun la kliento bezonas, devas esti en la konservejo kongrua kun la elektita amplekso. Malĝusta parigo produktas profilon, kiu importiĝas pure kaj poste fiaskas ĉe la unua konekto.

macOS prenas agordan profilon kun la administrata VPN-ŝarĝo, subskribitan kaj puŝitan tra MDM aŭ permane instalitan por provo. La identeco kaj la CA-ĉeno vojaĝas kiel apartaj ŝarĝoj, tial profilo povas instaliĝi sen plendo kaj tamen fiaski ĉe konekto. Kontrolu la liston de ŝarĝoj, ne nur la instalrezulton.

Linux dependas de la postaĵo malantaŭ NetworkManager, kaj strongSwan kaj la NetworkManager-kromprogramo estas apartaj pakaĵoj. Konektaj propraĵoj estas kromprogram-specifaj, ne ĝeneralaj VPN-ŝlosiloj, do ŝlosilo kopiita el alia kromprogramo ofte konserviĝas sen eraro kaj poste fiaskas ĉe aktivigo. Konstruu la konekton sur pura bildo por konfirmi, ke la kromprogramo ĉeestas tie, kie ĝi efektive ruliĝos.

La tri artefaktoj malsamas laŭ formato, sed ĉiu kodigas la samajn kvin kontraktliniojn. Tio estas la testo, ĉu artefakto estas finita: ĉiu linio estas reprezentita ie, kaj nenio kroma estis elpensita survoje.

Kontrolu itinerojn, solvilon kaj rekonekton sur pura konto

Konektite ne estas la akcepta testo. Sur Windows Get-VpnConnection montras la profilon kaj route print montras, ĉu la privata prefikso surteriĝis sur la tunela interfaco. Sur macOS scutil --nc list konfirmas la aktivan servon, dum scutil --dns montras la solvilan ordon, kiun la sistemo vere uzos.

Sur Linux nmcli connection show --active pruvas, ke la konekto staras, kaj resolvectl status montras DNS laŭ ligilo. Solvilo ĉeestanta en la konekta dosiero sed mankanta en la eligo laŭ ligilo signifas, ke dividita DNS ne estas aplikata. Tio estas la diferenco inter nomoj, kiuj solviĝas, kaj nomoj, kiuj solviĝas tra la tunelo, kaj ĝi ŝanĝas, kiu subtena teamo posedas la sekvan paŝon. Komparu la eligon laŭ ligilo antaŭ kaj post kiam la konekto leviĝas, ne nur poste.

Rulu la tutan kontrolon kiel freŝa konto sen kaŝmemoraj akreditaĵoj kaj sen atestilo instalita de administranto. Poste ripetu ĝin post paŭzo kaj vekiĝo, kaj ankoraŭfoje post devigo de rea enigo de akreditaĵoj. Tiuj du transiroj malkaŝas la plej multajn rekonektajn fiaskojn, kiujn unua konekto neniam montras.

Versiu la pakaĵon kaj konservu retrovojon

Etikedu ĉiun platforman pakaĵon per la kontrakta revizio, kiun ĝi realigas, kaj notu la klientajn kaj enirejajn versiojn, laŭ kiuj vi akceptis ĝin. Kiam konduto ŝanĝiĝas post klienta ĝisdatigo, la etikedo montras al kontrakto por retesti anstataŭ al dosiero por diveni.

Tenu la antaŭan pakaĵon por ĉiu platformo havebla, kaj skribu ĝian forigkomandon apude. Malinstali VPN-profilon ne estas la spegula bildo de ĝia instalado en Windows, macOS aŭ Linux, kaj la diferencoj aperas en la plej malbona momento. Ekzercu la forigon unufoje sur rezerva aparato, por ke la arkivo fariĝu plano anstataŭ espero.