Netgear OpenVPN: TUN y TAP escuchan en puertos distintos

Un teléfono se conecta a la VPN del router sin queja, y un portátil que usa un perfil de la misma página de descarga agota el tiempo. Nada de los certificados cambió entre esos dos intentos, porque el portátil nunca llegó al punto en que los certificados importan. El router publica escuchas separadas para TUN y TAP, y un perfil que funcione tiene que elegir la que corresponde a su propio tipo de dispositivo.

Decidir cuál de tres fallos candidatos perseguir es todo el trabajo aquí: el puerto, el tipo de dispositivo o la negociación del cifrado del canal de datos.

Tres cosas que tienen que coincidir

El tipo de dispositivo, la línea de interfaz del perfil y el puerto de escucha forman una sola elección, no tres. Un perfil que declara dev tun y apunta a la escucha TAP no puede completar la sesión, y lo contrario falla igual. Para su modelo y firmware, lea el puerto en la propia página VPN del router y no en una guía, porque los números cambian entre compilaciones. Anote el modelo y la versión de firmware junto a ese número para que la siguiente persona pueda verificarlo.

Los informes de campo mencionan un par como 12973 para TUN y 12974 para TAP en un firmware, y un número distinto en otro. Léalos como prueba de que las compilaciones difieren, no como constantes que copiar. El perfil necesita entonces el nombre de host adecuado a la distancia: el nombre DNS dinámico del router en lugar de una dirección WAN que cambiará.

Después de corregir el puerto y la línea de interfaz, el perfil parece una configuración de cliente normal con una línea remote y una línea dev. Si las dos no coinciden, ninguna cantidad de reintentos produce una sesión.

Lea el registro en el orden en que se imprime

Un cliente OpenVPN informa de los eventos en el orden en que ocurren, así que la última línea antes del silencio identifica la capa que hay que inspeccionar. Cuando la ejecución termina en TLS Error: TLS key negotiation failed, o simplemente espera una primera respuesta y se rinde, la comparación de certificados nunca ocurrió. Eso apunta a la accesibilidad, a la escucha o a un puerto que no tiene nada detrás. Nada de eso se repara sustituyendo el archivo CA.

Una ejecución que llega a VERIFY OK y luego falla está en otro sitio por completo, con sus propias causas. Separar esos dos desenlaces antes de tocar archivos evita el clásico rodeo por los paquetes de certificados que nunca se consultaron. Una vez completado el handshake pero sin que el túnel suba, mire la negociación del cifrado en lugar de la accesibilidad.

Añada la lista de cifrados que espera un cliente moderno

Los clientes OpenVPN recientes rechazan los valores predeterminados antiguos que el firmware doméstico sigue ofreciendo, y el síntoma es un fallo de negociación justo después de un handshake correcto. La solución es una línea de perfil que nombre lo que el cliente aceptará: ajuste data-ciphers a AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 y AES-128-CBC en ese orden. Cualquier algoritmo que el router no implemente simplemente nunca se selecciona, así que una lista más larga no cuesta nada más que una negociación algo más larga.

Enumerar cifrados no le enseña al router uno que no tiene. Si la negociación sigue fallando, compruebe si la página del router tiene su propia configuración de cifrado y si esa configuración incluye al menos una entrada que el cliente acepte. Dos listas sin miembro común producen exactamente el mismo fallo que un puerto equivocado, y por eso ambos extremos merecen una mirada.

Importe una vez en lugar de editar copias a mano

Importar el archivo corregido en NetworkManager evita una carpeta llena de perfiles ligeramente distintos: nmcli connection import type openvpn file client.ovpn, y luego actívelo por nombre. Conserve el perfil importado como la única copia que edita y elimine los duplicados que se acumulan de descargas repetidas.

Después pruebe desde fuera de la LAN. Conectarse desde la misma red demuestra muy poco, porque el tráfico puede no atravesar el túnel en absoluto. Confirme que una petición sale realmente por el router, no solo que el cliente muestra un estado conectado.

Decida qué hacer con los avisos

El firmware doméstico suele acuñar su propia autoridad de certificación, y los clientes se quejan de la verificación de maneras que el firmware no puede suprimir. Juzgue si esa queja importa para lo que protege en lugar de tratar cada aviso como fatal, y no desactive la verificación globalmente para silenciar un solo mensaje. Un aviso que ha evaluado es un riesgo documentado; una configuración de verificación que ha desactivado no lo está.

Cuando el firmware no ofrece ninguna forma admitida de corregir un aviso que sí importa, esa carencia aboga por alojar la VPN en otro sitio. Elegir entre reparar el perfil, aceptar el aviso y trasladar el punto final es una decisión sobre cuánto confía en ese certificado. Tómela deliberadamente y anote qué opción eligió, en lugar de ir pulsando diálogos hasta que el icono se ponga verde.