tun precreado de OpenVPN: compare los dos modelos de propiedad

Alguien creó tun1 de antemano, el perfil dice dev tun1, y la conexión sigue sin engancharse. El nombre que existe en el host no dice casi nada, porque el enganche depende del espacio de nombres, del tipo de dispositivo, de quién es dueño del enlace y de lo que se le permite hacer al demonio. Reutilizar un dispositivo también obliga a una decisión que la configuración por defecto esconde: qué componente escribe las direcciones y las rutas. Los modos de fallo de los dos arreglos difieren mucho más que las líneas de configuración, así que decida antes de editar un perfil.

Un nombre no es un enganche

dev tun1 pide a OpenVPN esa interfaz con nombre, y las compilaciones tradicionales de espacio de usuario intentarán abrirla. Si el nombre no sigue el patrón habitual de tun o tap, el perfil también necesita un dev-type coincidente, porque el tipo nunca se infiere de una cadena. Un dispositivo TAP no es un dispositivo TUN con otra etiqueta: enganchar el equivocado falla directamente o produce un enlace que transporta tramas que nadie espera. Compruebe el tipo antes que cualquier otra cosa, ya que toda comprobación posterior asume que ambos lados coinciden en él. A partir de ahí, confirme que el proceso puede abrir realmente el dispositivo, no solo verlo.

dev tun1
dev-type tun

La interfaz de red y /dev/net/tun son objetos distintos: una es un enlace dentro de un espacio de nombres, la otra es el dispositivo de caracteres que un programa de espacio de usuario usa para engancharse. documentación de TUN/TAP de Linux describe esa ruta de enganche y las reglas de propiedad para dispositivos persistentes. Un intérprete de órdenes root que pueda ejecutar ip link solo demuestra que el intérprete tiene privilegios, no que el demonio los tenga. La propiedad del nodo de dispositivo, el conjunto de capacidades del servicio y el usuario con el que se ejecuta tienen que alinearse todos antes de que la apertura tenga éxito.

Un dispositivo que existe y no se puede abrir es un problema de propiedad, no de encaminamiento. Trátelo como tal mientras depura, o la tarde se irá leyendo tablas de rutas que nunca fueron el problema.

Quién configura el enlace: dos modelos de propiedad

En el primer modelo, OpenVPN configura direcciones y rutas como parte de levantar la conexión. Ese es el comportamiento por defecto y el más fácil de razonar, porque un solo componente crea el estado y lo vuelve a eliminar. En el segundo modelo, un gestor externo es dueño de la interfaz, y ifconfig-noexec impide que OpenVPN ejecute sus órdenes de configuración de direcciones y entrega los parámetros a scripts en su lugar. El gestor tiene entonces que aplicar por sí mismo la configuración local y de par correcta, lo que es más trabajo de lo que sugiere el nombre de la opción. Elegir entre los dos es una cuestión de quién puede cambiar el enlace mientras está activo.

ifconfig-noexec cubre solo las direcciones: la tabla de rutas no se toca, y la configuración de rutas pertenece a route-noexec. Trate las dos directivas como controles separados con dueños separados, porque establecer una y suponer la otra es una fuente habitual de enlaces a medio configurar. Elija exactamente un dueño por capa, las direcciones en un sitio y las rutas en otro. Un gestor de red y un ayudante de VPN que ambos escriben direcciones es cómo una desconexión borra un estado del que la otra parte todavía depende.

Inspeccione el dispositivo desde el espacio de nombres que importa

Inspeccione el dispositivo desde el espacio de nombres en el que se ejecuta el proceso VPN, no desde el que su intérprete de órdenes ocupa por casualidad. Las dos órdenes siguientes responden a preguntas distintas, y la diferencia aparece cuando un host ve una interfaz que un contenedor no puede ver. Ejecútelas en el orden indicado, porque la segunda solo tiene sentido una vez que sabe si el enlace existe siquiera.

ip -details link show dev tun1
ip tuntap show

La primera orden imprime el enlace tal como lo ve el núcleo, incluidos indicadores y tipo de interfaz, y así confirma que este es el dispositivo que quería. La segunda lista las entradas persistentes de tun/tap, que existen sin que ningún proceso las mantenga. Una interfaz que espera a su dueño previsto es una situación distinta de un túnel activo enganchado a otra VPN, y solo la segunda explica por qué falla su propio enganche. Encuentre el proceso que mantiene el dispositivo antes de cambiar nada, ya que una entrada persistente y una interfaz ocupada tienen soluciones distintas.

El soporte de multiqueue es un arreglo específico de controlador con sus propios requisitos, no un permiso para que procesos no relacionados compartan una interfaz. La sesión activa de otro dueño es un problema de coordinación, y ninguna edición de perfil lo resuelve.

Dos tipos distintos de persistencia

La persistencia del núcleo y persist-tun describen vidas útiles que es fácil confundir y caro confundir. Un dispositivo persistente existe con independencia de cualquier proceso, así que sobrevive a una parada y puede reutilizarse en el siguiente arranque. persist-tun conserva recursos a través de los reinicios suaves admitidos dentro de un solo proceso de OpenVPN, un horizonte mucho más corto. Ninguna de las dos promete que detener el servicio deje las rutas y las direcciones en su sitio, y una interfaz que sigue visible no es prueba de una sesión cifrada que funcione.

Confirme también el backend, porque una interfaz precreada no dice nada sobre qué implementación la abrirá. Las compilaciones comunitarias que llevan la ruta de datos directa intentarán usarla a menos que el diseño diga lo contrario. Cuando una versión admite el interruptor, disable-dco selecciona la ruta de espacio de usuario; los motores más antiguos y otros clientes no tienen esa directiva, así que mantenga la condición de versión junto a la opción en lugar de suponer que se aplica.

Qué se rompe cuando solo se prueba el arranque

Un acuerdo de propiedad puede pasar la primera prueba y fallar la última, lo que convierte el arranque en una comprobación pobre por sí sola. Observe dos transiciones en su lugar: un reinicio suave y una parada completa seguida de un arranque.

systemctl status openvpn-client@lab
ip -details link show dev tun1

El arranque es el caso fácil: la unidad arranca, el enlace aparece y la salida de estado nombra el perfil que se cargó. El enganche es el momento en que el demonio abre el dispositivo, así que ejecute la comprobación del enlace después de que la unidad informe que está activa, no antes. Si el enlace existe mientras el estado todavía está activando, está viendo un dispositivo persistente al que nadie se ha enganchado aún, no un túnel en funcionamiento. Haga pasar tráfico real por el enlace antes de continuar, porque una interfaz enganchada sin una ruta utilizable sigue siendo un fallo.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Un reinicio suave debería dejar la sesión utilizable y los recursos intactos, que es el trabajo que persist-tun hace. Una parada completa es donde un gestor externo se revela: si el enlace o sus direcciones sobreviven a la parada, alguien más es su dueño, y eso es o bien el estado que documentó o bien el error que acaba de encontrar. Anote ambas observaciones junto al perfil, para que el siguiente cambio parta de evidencias en lugar de un diagrama.