Configuración de VPN en Mac: elija el cliente que encaja con su perfil

Configure el cliente que indique su operador de VPN y luego demuestre el túnel con el recurso privado que realmente necesita. Un Mac puede guardar una configuración VPN nativa en Ajustes del Sistema, pero un archivo OpenVPN o WireGuard necesita software que entienda el formato, y son rutas de configuración distintas. El tipo de credencial decide cómo fallará el inicio de sesión, así que léalo antes de escribir nada. Juzgue el resultado por lo que devuelve el recurso privado, no por el icono de la barra de menús.

Ajuste el cliente al perfil que recibió

Empiece por el archivo o las instrucciones que envió su operador, no por una lista de protocolos de un sitio de descargas. El formulario VPN nativo de Ajustes del Sistema maneja determinados tipos; un perfil OpenVPN o una configuración WireGuard necesita una aplicación que los analice. Un Mac gestionado puede recibir ya su conexión de la gestión de dispositivos, y añadir un segundo perfil encima produce un conflicto en lugar de una configuración. Mire qué existe antes de instalar nada.

El método de inicio de sesión viene del perfil y suele ser uno de tres: una contraseña de cuenta, un certificado de cliente o una frase de acceso que desbloquea una clave privada. Una contraseña incorrecta y un certificado rechazado detienen ambos la conexión, pero no se leen igual, y solo uno de ellos se cura restableciendo una contraseña de cuenta. Lea el rechazo antes de cambiar nada: un certificado caducado o no fiable sigue fallando tras restablecer la contraseña, mientras que una contraseña mala falla de inmediato, en el primer intento.

Mantenga el material privado fuera de los registros compartidos. La frase de acceso de una clave, un certificado de cliente y su clave no pertenecen a un hilo de chat con un colega, y una captura del editor de perfiles suele revelar más de lo que espera quien la envía. Si el operador entrega un archivo importable, impórtelo en lugar de reescribir los valores a mano.

Demuestre que funciona en el recurso, no en el icono

Un perfil de trabajo a menudo solo encamina destinos de oficina, así que la dirección pública que ve al navegar puede seguir igual mientras la aplicación privada funciona. En un perfil de salida personal la dirección que ve desde fuera debe cambiar, y en un perfil de trabajo normalmente no. Mida esa diferencia antes de concluir que el túnel está roto.

Luego abra el recurso que realmente necesita: el recurso compartido de archivos, la página de administración, el host de la base de datos. Que una página de inicio cargue por el túnel demuestra que el túnel transporta algo de tráfico, no que transporte el tráfico que pretendía. Si el navegador sigue mostrando la dirección original cuando el perfil debería cambiarla, compare tres cosas: la aplicación en uso, la familia de direcciones y la política de proxy. Un proxy del navegador o una ruta IPv6 pueden desviar el tráfico fuera de la VPN mientras el túnel está sano.

Donde el cliente expone una tabla de enrutamiento, lea la ruta predeterminada y la ruta del túnel. Ese par registra qué diseño desplegó realmente.

Cuando deja de funcionar, encuentre la capa que se rompió

Una configuración que funcionaba antes suele romperse porque algo se unió al camino: un segundo cliente VPN, un agente de seguridad, un filtro de contenido, una extensión de red nueva. Use los diagnósticos propios del producto en lugar de borrar preferencias o restablecer la pila de red, que es una esperanza y no un diagnóstico. Relacione el fallo con un evento —reposo, un cambio de Wi-Fi, un inicio de sesión en el portal o una actualización del cliente— y anote si se repite. Un desencadenante repetible debe constar en el ticket con la hora en que ocurrió.

Los nombres fallan de forma distinta a las rutas. A un host privado se llega por su nombre completo documentado, y los nombres cortos de oficina dependen de un resolutor interno más un dominio de búsqueda que solo existe en la ruta corporativa. Cambie ese resolutor por un servicio DNS público y los nombres cortos dejan de resolverse del todo, lo que parece un túnel roto pero no lo es.

scutil --dns
dscacheutil -q host -a name intranet.example.com

En la salida de scutil --dns, busque el resolutor cuyo dominio de búsqueda coincida con su dominio corporativo y lea el servidor de nombres al que apunta; las entradas listadas en la configuración de DNS muestran qué resolutor aporta cada interfaz. Cuando el resolutor corporativo solo aparece para otra interfaz, o el navegador ejecuta su propio DNS cifrado, una aplicación resuelve el nombre mientras todo lo demás falla.

Quite un perfil que ya no necesite mediante el mecanismo que lo instaló, porque borrar una entrada local deja viva la cuenta del lado del servidor y un cliente antiguo todavía puede reclamar las mismas rutas. En un Mac gestionado, el proceso de retirada del administrador es el que cuenta. Anote el nombre del perfil, la dirección del servidor y el recurso que funciona antes de quitar nada, para que la recuperación no empiece de cero.