OpenVPN TAP en macOS: compruebe el cliente antes de depurar

Un perfil antiguo llega a un Mac actual, el cliente lo importa sin protestar y la conexión se cae o nunca pasa tráfico. Antes de dedicar una tarde a los certificados, lea la línea de dispositivo del perfil. Si dice dev tap, está pidiendo al cliente una interfaz de tipo Ethernet y, en macOS, es en esa petición donde terminan la mayoría de estas sesiones.

Paso 1: confirme que el perfil realmente pide TAP

Los perfiles se renombran, se envuelven y se vuelven a exportar, así que revise el archivo que realmente importó. Busque la directiva de dispositivo y cualquier include que pueda anularla. Dos líneas de salida resuelven la pregunta en la mayoría de los casos. Cuando aparecen tanto dev como dev-type, gana la directiva posterior, y ese es justo el tipo de detalle que oculta un perfil copiado.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Si el archivo contiene dev tap o dev tap0, el cliente debe implementar una interfaz TAP. Si contiene dev tun, el resto de este artículo no se aplica y el fallo está en otro sitio.

Anote el nombre y la versión del cliente, la versión de macOS y de dónde salió el perfil. Esos tres hechos deciden cuál de los dos caminos siguientes es siquiera posible.

Paso 2: sepa qué cambia realmente el modo de dispositivo

Una interfaz TUN transporta paquetes IP. El cliente lee y escribe paquetes dirigidos a un par IP, y el sistema operativo los enruta como cualquier otra interfaz.

Una interfaz TAP transporta tramas Ethernet, incluidas la difusión y ARP. Eso es lo que permite que un servidor puente reparta direcciones por DHCP y que un cliente descubra dispositivos a gritos, y por eso algunos diseños heredados dependen de ello.

El coste es que TAP necesita un controlador que presente al sistema una interfaz Ethernet. Apple ha retirado el modelo de extensión del núcleo en el que se basaban los controladores TAP antiguos para Mac, y su API sustituta no aparece por arte de magia dentro de clientes que nunca se actualizaron para usarla. Una capacidad de plataforma y un producto ya entregado son cosas distintas.

Paso 3: elija entre un cliente compatible y una migración

Hay dos caminos honestos. El primero es un cliente cuyo editor declara, para su versión de macOS y su hardware, que admite la disposición TAP que necesita. No una publicación de foro de hace cuatro años ni un instalador archivado: una declaración actual más una conexión de prueba.

El segundo es trasladar el servicio a TUN, lo que es un cambio de servidor tanto como de cliente. Requiere una topología enrutada, un grupo de direcciones, rutas empujadas para las redes remotas y un camino de vuelta desde esas redes al grupo.

Lo que no funciona es editar tap a tun en su copia local y esperar. El servidor sigue haciendo puente, el cliente ahora habla IP y nada concuerda.

Paso 4: reúna los hechos antes de cambiar un servicio que funciona

Deje intacto el perfil original y haga una copia para experimentos. Un archivo que puede restaurar en un minuto vale más que una carpeta ordenada. Cuando el sustituto funcione, borre la copia a propósito en lugar de dejar dos perfiles que parezcan idénticos en una lista. Ese único hábito evita la mayor parte de la confusión que sigue a una migración fallida. Registre el comportamiento actual para poder demostrar qué cambió: anote si el túnel sube, si obtiene una dirección, si puede llegar a un host conocido y si funciona la resolución de nombres.

Haga tres preguntas al propietario de la puerta de enlace. ¿El servidor funciona con una topología de puente o enrutada? ¿Qué prefijos remotos deberían ser accesibles? ¿Y hay una ventana de mantenimiento para cambiar la configuración, o se espera que funcione sin tocar el servidor?

Las respuestas determinan si esta tarde resuelve un problema de cliente o si la próxima semana planifica un cambio de red.

Paso 5: verifique la migración desde ambos extremos

Cuando el servidor tenga una configuración enrutada y usted tenga un perfil que encaje, pruebe en este orden: el túnel se establece, el cliente recibe una dirección del nuevo grupo, un host del lado remoto responde y un nombre se resuelve mediante el ajuste DNS empujado.

Luego pruebe lo que antes dependía del comportamiento de Ethernet. Si una aplicación descubría dispositivos por difusión, no los encontrará por un túnel enrutado, y ninguna configuración de cliente lo recupera. Esa aplicación necesita una dirección conocida, un host auxiliar local o un método de descubrimiento distinto.

Termine reconectando y reiniciando una vez, porque un perfil que solo funciona al primer intento suele significar que las rutas empujadas o el ajuste DNS no se aplican al reconectar.

Cuando sigue fallando, lea el primer error

Un cliente que no puede crear la interfaz lo dice en su registro, normalmente en las primeras líneas. Un cliente que la crea y luego no consigue autenticarse ha superado por completo la cuestión del dispositivo, y seguir persiguiendo TAP desperdicia la sesión.

Conserve el perfil original y la configuración que funciona hasta que el sustituto esté probado. Deshacer un cambio de cliente es rápido; reconstruir una red puente que alguien desmontó por una corazonada no lo es.