TUN/TAP: argumento no válido — desajuste del entramado de OpenVPN

El cliente se autentica, el registro dice conectado y ningún paquete cruza el túnel. El servidor termina el intento con write to TUN/TAP: Invalid argument (code=22), que parece una falla del controlador y normalmente no lo es. En routers y servidores Linux pequeños, esa línea suele significar que los dos extremos no se ponen de acuerdo sobre cómo se entraman los paquetes de datos, así que el núcleo rechaza el búfer descifrado que se le entregó. El enrutamiento aún no se ha probado en ese punto.

Una tabla de rutas correcta y un acuerdo de entramado roto se ven igual desde el cliente: conectado, y nada funciona.

El túnel sube y nada lo cruza

Los errores de escritura en el dispositivo del túnel ocurren después del descifrado y antes del enrutamiento. El demonio descifra un paquete, lo entrega a la interfaz, y la interfaz lo rechaza porque el búfer no coincide con lo que espera ese dispositivo. El código 22 es la respuesta genérica de argumento no válido, así que la información útil es la capa: esta es la ruta de datos y no el handshake. Si el tráfico ayer funcionaba y hoy se detuvo sin ningún cambio de configuración, sospeche de una actualización de paquete o firmware que movió un valor predeterminado antes de sospechar de la red.

Lea el registro alrededor de la configuración del canal de datos en lugar del primer error. El modo de compresión negociado, el tipo dev y las opciones empujadas aparecen todos con mayor verbosidad, y le dicen cuál de los tres desajustes tiene.

La compresión es entramado, no ancho de banda

Con la compresión activada, cada paquete de datos lleva una cabecera que describe cómo se codificó, y ambos extremos deben ponerse de acuerdo sobre esa cabecera. Un servidor que todavía lleva comp-lzo de una configuración de ejemplo antigua, emparejado con un cliente que no tiene línea de compresión, produce exactamente este error: el servidor espera una cabecera que el cliente nunca escribió. Mezclar comp-lzo con compress lz4-v2 falla de la misma manera, ya que los algoritmos difieren aunque ambos se llamen compresión. La opción es un contrato de entramado y no una función de ancho de banda en los enlaces modernos.

El comportamiento de las versiones añade una trampa. La serie 2.5 empezó a emitir avisos de obsolescencia para las opciones de compresión, y 2.6 traza una línea entre rechazar los paquetes comprimidos y simplemente dejar los datos sin comprimir. Por lo tanto, una actualización de firmware del router puede cambiar el acuerdo efectivo sin que nadie edite el túnel.

Alinee ambos extremos o quítelo de los dos

Enumere cada directiva de compresión: el archivo del servidor, cualquier opción empujada, los archivos específicos del cliente y el perfil del cliente. comp-lzo en el servidor necesita la misma palabra en el cliente, y adaptive es el valor predeterminado heredado que la opción desnuda suele significar en compilaciones antiguas. El interruptor de la GUI del router etiquetado LZO o compresión escribe esa misma opción, así que ajústelo para que coincida en lugar de mezclar algoritmos. No asuma que un nombre de aspecto similar sea compatible.

Si no se desea la compresión, elimínela deliberadamente de ambos extremos. allow-compression no en el servidor rechaza los paquetes comprimidos, pero solo cuando los clientes han dejado de ofrecerlos; aplicarlo mientras un cliente todavía empuja compresión recrea el desajuste en la otra dirección.

Compruebe el empuje y el tipo de dispositivo

Un servidor puede empujar una directiva de compresión desde su archivo principal o desde uno específico del cliente, y un cliente puede descartar las opciones empujadas con pull-filter. Conecte un cliente con verbosidad 4, lea lo que anunció el servidor frente a lo que aceptó el cliente, y luego confirme que ningún filtro lo eliminó. Si ambos lados ahora coinciden y el error persiste, mire el tipo de dispositivo: dev tap en un extremo y dev tun en el otro no pueden intercambiar tramas, y el núcleo rechaza la escritura de la misma manera.

Un despliegue de TAP con puente necesita un puente real en el servidor, no solo un nombre de dispositivo diferente. Renombrar una interfaz a tap0 sin añadirla a un puente produce un dispositivo que acepta la escritura y no va a ninguna parte.

Luego verifique con un cliente y un destino: haga ping a la dirección del túnel del servidor, luego a un host en su LAN. El primero demuestra el canal de datos y el segundo el reenvío.