¿Puede un solo servicio de VPN cubrir los escritorios Windows, Mac y Linux?

Tres portátiles en un equipo, tres menús de VPN distintos y un tique que dice que la conexión funciona en todas partes menos en el Mac. El plan que hay detrás de esos clientes puede ser idéntico aunque los menús no lo sean. Lo que tiene que cuadrar es más estrecho de lo que suponen la mayoría de los despliegues: una identidad de puerta de enlace, un tipo de credencial, un conjunto de rutas y una política de resolutor. Anote esos cuatro puntos antes de que alguien exporte un perfil, y el trabajo de plataformas se convierte en una lista de comprobación en lugar de una investigación.

Empiece por el contrato de acceso, no por el archivo del cliente

El contrato de acceso son cinco líneas que un revisor puede comprobar sin abrir una consola del proveedor. Nombra los prefijos privados que deben ser accesibles, los nombres internos que deben resolverse, el resolutor que responde por ellos, el tráfico al que se permite quedarse en la ruta local y el certificado de la puerta de enlace que el cliente debería esperar. Todo lo demás del despliegue es una traducción de esas líneas a un formato de archivo.

Un ejemplo de oficina hace concreta la forma: servidores de aplicaciones en 10.60.0.0/16, nombres privados bajo corp.example, un resolutor interno en 10.61.0.53 y la navegación normal dejada en la ruta que el dispositivo ya usa. El último punto es una decisión de política y no un valor por defecto del cliente, y varios clientes enviarán todo por el túnel si nadie dice lo contrario. Registre el contrato con fecha y responsable, porque ese registro es lo que luego le dirá si cambió el túnel o la política.

Elija un protocolo y un par de autenticación que pueda defender

IKEv2 con autenticación de puerta de enlace basada en certificado y EAP para el usuario es la elección habitual cuando las tres plataformas deben funcionar sin software adicional, ya que Windows, macOS y NetworkManager incluyen cada uno un cliente IKEv2. El problema es que admitir IKEv2 describe una etiqueta, no un conjunto de funciones. Los métodos EAP, las claves con respaldo de hardware, la asignación de certificado a cuenta y la reconexión automática se implementan por plataforma. Una combinación que funciona en dos de las tres es lo bastante común como para suponerla hasta que se pruebe.

Pruebe el par en cada plataforma objetivo antes de escribir la guía de despliegue, no después. Una puerta de enlace que ofrece tanto EAP-MSCHAPv2 como EAP-TLS le da margen para retroceder, siempre que la retirada esté documentada como soportada y no se descubra durante un incidente. Dos caminos soportados son un seguro barato; un tercer camino indocumentado es un tique futuro.

Cuando ningún par cubre los tres clientes, las opciones honestas son añadir un cliente, añadir un perfil de puerta de enlace o reducir la lista de plataformas soportadas. Desactivar la validación de certificados en la plataforma que más se queja no es una de ellas. Ese cambio convierte una brecha de compatibilidad en un riesgo de interceptación, y ningún paso posterior del despliegue lo repara.

Construya un artefacto por plataforma a partir del contrato

Windows toma un perfil VPNv2, entregado por MDM o creado localmente con Add-VpnConnection y su carga XML. Las partes que escuecen son el ámbito y la confianza. Un perfil con ámbito de dispositivo y un perfil con ámbito de usuario se instalan en almacenes distintos, así que el certificado que necesita el cliente debe estar en el almacén que coincide con el ámbito elegido. Un emparejamiento incorrecto produce un perfil que se importa limpiamente y luego falla en la primera conexión.

macOS toma un perfil de configuración con la carga VPN gestionada, firmado y enviado por MDM o instalado a mano para un piloto. La identidad y la cadena de CA viajan como cargas separadas, por eso un perfil puede instalarse sin queja y aun así fallar al conectar. Revise la lista de cargas, no solo el resultado de la instalación.

Linux depende del backend que hay detrás de NetworkManager, y strongSwan y el complemento de NetworkManager son paquetes separados. Las propiedades de conexión son específicas del complemento, no claves VPN genéricas, así que una clave copiada de otro complemento a menudo se guarda sin error y luego falla al activarse. Construya la conexión en una imagen limpia para confirmar que el complemento está donde realmente se ejecutará.

Los tres artefactos difieren en formato, pero cada uno codifica las mismas cinco líneas del contrato. Esa es la prueba de si un artefacto está terminado: cada línea está representada en algún sitio y no se inventó nada extra por el camino.

Verifique rutas, resolutor y reconexión en una cuenta limpia

Conectado no es la prueba de aceptación. En Windows, Get-VpnConnection muestra el perfil y route print muestra si el prefijo privado llegó a la interfaz del túnel. En macOS, scutil --nc list confirma el servicio activo mientras scutil --dns muestra el orden de resolutores que el sistema usará de verdad.

En Linux, nmcli connection show --active demuestra que la conexión está levantada y resolvectl status muestra el DNS por enlace. Un resolutor presente en el archivo de conexión pero ausente en la salida por enlace significa que el DNS dividido no se está aplicando. Esa es la diferencia entre nombres que se resuelven y nombres que se resuelven por el túnel, y cambia qué equipo de soporte tiene el siguiente paso. Compare la salida por enlace antes y después de que la conexión suba, no solo después.

Ejecute toda la comprobación como una cuenta nueva, sin credenciales en caché y sin certificado instalado por un administrador. Luego repítala tras una suspensión y reanudación, y una vez más tras forzar una reintroducción de credenciales. Esas dos transiciones sacan a la luz la mayoría de los fallos de reconexión que una primera conexión nunca muestra.

Versione el paquete y mantenga una ruta de reversión

Etiquete cada paquete de plataforma con la revisión del contrato que implementa, y anote las versiones de cliente y puerta de enlace contra las que lo aceptó. Cuando el comportamiento cambie tras una actualización del cliente, la etiqueta apunta a un contrato que volver a probar en lugar de a un archivo que adivinar.

Mantenga recuperable el paquete anterior de cada plataforma y escriba junto a él su comando de eliminación. Desinstalar un perfil de VPN no es la imagen especular de instalarlo en Windows, macOS o Linux, y las diferencias aparecen en el peor momento posible. Ensaye la eliminación una vez en un dispositivo de repuesto para que el archivo se convierta en un plan y no en una esperanza.