Pode un só servizo de VPN cubrir os escritorios Windows, Mac e Linux?
Un só plan de acceso pode servir escritorios Windows, Mac e Linux, pero só despois de fixar a identidade da pasarela, a credencial, as rutas e a política do resolutor.
Tres portátiles nun equipo, tres menús de VPN distintos e un tícket que di que a conexión funciona en todas partes menos no Mac. O plan detrás deses clientes pode ser idéntico aínda que os menús non o sexan. O que ten que cadrar é máis estreito do que supoñen a maioría dos despregamentos: unha identidade de pasarela, un tipo de credencial, un conxunto de rutas e unha política de resolutor. Anote eses catro puntos antes de que alguén exporte un perfil, e o traballo de plataformas convértese nunha lista de comprobación en lugar dunha investigación.
Comece polo contrato de acceso, non polo ficheiro do cliente
O contrato de acceso son cinco liñas que un revisor pode comprobar sen abrir unha consola do provedor. Nomea os prefixos privados que deben ser accesibles, os nomes internos que deben resolverse, o resolutor que responde por eles, o tráfico ao que se permite quedarse na ruta local e o certificado da pasarela que o cliente debería agardar. Todo o demais do despregamento é unha tradución desas liñas a un formato de ficheiro.
Un exemplo de oficina fai concreta a forma: servidores de aplicacións en 10.60.0.0/16, nomes privados baixo corp.example, un resolutor interno en 10.61.0.53 e a navegación normal deixada na ruta que o dispositivo xa usa. O último punto é unha decisión de política e non un valor por defecto do cliente, e varios clientes enviarán todo polo túnel se ninguén di o contrario. Rexistre o contrato con data e responsable, porque ese rexistro é o que lle dirá despois se cambiou o túnel ou a política.
Escolla un protocolo e un par de autenticación que poida defender
IKEv2 con autenticación de pasarela baseada en certificado e EAP para o usuario é a elección habitual cando as tres plataformas deben funcionar sen software adicional, xa que Windows, macOS e NetworkManager inclúen cada un un cliente IKEv2. O problema é que admitir IKEv2 describe unha etiqueta, non un conxunto de funcións. Os métodos EAP, as claves con respaldo de hardware, a asignación de certificado a conta e a reconexión automática implémentanse por plataforma. Unha combinación que funciona en dúas das tres é o bastante común como para supoñela ata que se probe.
Probe o par en cada plataforma obxectivo antes de escribir a guía de despregamento, non despois. Unha pasarela que ofrece tanto EAP-MSCHAPv2 como EAP-TLS dálle marxe para retroceder, sempre que a retirada estea documentada como soportada e non se descubra durante un incidente. Dous camiños soportados son un seguro barato; un terceiro camiño non documentado é un tícket futuro.
Cando ningún par cobre os tres clientes, as opcións honestas son engadir un cliente, engadir un perfil de pasarela ou reducir a lista de plataformas soportadas. Desactivar a validación de certificados na plataforma que máis se queixa non é unha delas. Ese cambio converte unha fenda de compatibilidade nun risco de interceptación, e ningún paso posterior do despregamento o repara.
Constrúa un artefacto por plataforma a partir do contrato
Windows toma un perfil VPNv2, entregado por MDM ou creado localmente con Add-VpnConnection e a súa carga XML. As partes que escocen son o ámbito e a confianza. Un perfil con ámbito de dispositivo e un perfil con ámbito de usuario instálanse en almacéns distintos, así que o certificado que necesita o cliente debe estar no almacén que coincide co ámbito escollido. Un emparellamento incorrecto produce un perfil que se importa limpiamente e despois falla na primeira conexión.
macOS toma un perfil de configuración coa carga VPN xestionada, asinado e enviado por MDM ou instalado a man para un piloto. A identidade e a cadea de CA viaxan como cargas separadas, por iso un perfil pode instalarse sen queixa e aínda así fallar ao conectar. Revise a lista de cargas, non só o resultado da instalación.
Linux depende do backend que hai detrás de NetworkManager, e strongSwan e o complemento de NetworkManager son paquetes separados. As propiedades de conexión son específicas do complemento, non claves VPN xenéricas, así que unha clave copiada doutro complemento a miúdo gárdase sen erro e despois falla ao activarse. Constrúa a conexión nunha imaxe limpa para confirmar que o complemento está onde realmente se executará.
Os tres artefactos difiren de formato, pero cada un codifica as mesmas cinco liñas do contrato. Esa é a proba de se un artefacto está rematado: cada liña está representada nalgún sitio e non se inventou nada extra polo camiño.
| 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 |
Verifique rutas, resolutor e reconexión nunha conta limpa
Conectado non é a proba de aceptación. En Windows, Get-VpnConnection mostra o perfil e route print mostra se o prefixo privado chegou á interface do túnel. En macOS, scutil --nc list confirma o servizo activo mentres scutil --dns mostra a orde de resolutores que o sistema usará de verdade.
En Linux, nmcli connection show --active demostra que a conexión está levantada e resolvectl status mostra o DNS por ligazón. Un resolutor presente no ficheiro de conexión pero ausente na saída por ligazón significa que o DNS dividido non se está aplicando. Esa é a diferenza entre nomes que se resolven e nomes que se resolven polo túnel, e cambia que equipo de soporte ten o seguinte paso. Compare a saída por ligazón antes e despois de que a conexión suba, non só despois.
Executar a comprobación enteira como unha conta nova, sen credenciais en caché e sen certificado instalado por un administrador. Logo repítaa tras unha suspensión e reanudación, e unha vez máis tras forzar unha reintrodución de credenciais. Esas dúas transicións sacan á luz a maioría dos fallos de reconexión que unha primeira conexión nunca mostra.
Versione o paquete e manteña unha ruta de reversión
Etiquete cada paquete de plataforma coa revisión do contrato que implementa, e anote as versións de cliente e pasarela contra as que o aceptou. Cando o comportamento cambie tras unha actualización do cliente, a etiqueta apunta a un contrato que volver probar en lugar de a un ficheiro que adiviñar.
Manteña recuperable o paquete anterior de cada plataforma e escriba xunto a el o seu comando de eliminación. Desinstalar un perfil de VPN non é a imaxe especular de instalalo en Windows, macOS ou Linux, e as diferenzas aparecen no peor momento posible. Ensaiar a eliminación unha vez nun dispositivo de reposto para que o arquivo se converta nun plan e non nunha esperanza.