OpenVPN en un VPS: no hay dispositivo /dev/net/tun que abrir

El primer arranque falla con un mensaje sobre /dev/net/tun o un dispositivo TUN/TAP que no se puede abrir. Los certificados aún no se han leído, así que nada del perfil está implicado. El demonio pide al núcleo un objeto que este invitado no tiene.

Ese objeto es un dispositivo de caracteres respaldado por el módulo tun. Que pueda crearlo depende de quién posee el núcleo.

Qué pide el demonio al núcleo

OpenVPN abre /dev/net/tun y pide al controlador una interfaz. El controlador es el módulo tun, y el nodo del dispositivo es el manejador que el espacio de usuario usa para alcanzarlo. Si el módulo no está cargado, el nodo puede faltar o la apertura puede fallar. Ninguna de las dos condiciones se corrige editando server.conf.

Lea el error primero como una pregunta de plataforma. Un error de configuración aparece después de que se abra el dispositivo, no antes.

VM o invitado con núcleo compartido

En KVM, Xen u otra máquina virtual completa usted controla el núcleo. Puede cargar módulos y crear el nodo. En OpenVZ, Virtuozzo o un contenedor al estilo LXC el invitado comparte el núcleo del anfitrión, así que root dentro no puede cargar un módulo que el anfitrión no ha cargado.

Por tanto, el mismo fallo tiene dos dueños muy distintos. En el primer caso puede arreglarlo desde dentro de la instancia. En el segundo está pidiendo al anfitrión, o al proveedor, que exponga algo.

Ejecute ls -l /dev/net/tun, lsmod | grep tun y ip -brief link show antes de decidir en qué caso está.

En una VM, cargue el módulo al arrancar

En una máquina virtual, modprobe tun suele crear el nodo del dispositivo. Compruebe que aparece y luego haga permanente la carga mediante la configuración de módulos de la distribución en lugar de confiar en un comando escrito una vez. Un nodo que desaparece tras un reinicio se convierte en el mismo tique el mes que viene.

Compruebe también que el núcleo que arrancó tenga el módulo. Un núcleo de proveedor recortado puede no tenerlo.

Si el nodo existe pero la apertura sigue fallando, los permisos y los números major/minor del dispositivo son los siguientes sospechosos. Son correcciones locales, no peticiones al proveedor.

En un contenedor, el anfitrión posee el dispositivo

En un contenedor, el dispositivo y la capacidad son dos requisitos separados. El runtime debe pasar /dev/net/tun, y el contenedor necesita la capacidad de red para crear una interfaz. Un runtime sin root que no conceda ninguna de las dos seguirá produciendo el mismo error de apertura por mucho que se escriba el perfil. Muchos anfitriones OpenVZ muestran un conmutador TUN/TAP en el panel del cliente, y activarlo más un reinicio suele ser toda la solución.

Pregunte al proveedor dos cuestiones precisas: está cargado el módulo tun en el anfitrión, y está disponible el dispositivo dentro de esta instancia. Un tique vago recibe una respuesta vaga.

Por qué reconstruir el módulo rara vez ayuda

Construir un módulo dentro del invitado rara vez ayuda. La compilación necesita la configuración del núcleo exactamente en ejecución, y /proc/config.gz es opcional y a menudo ausente en imágenes mínimas. Incluso un módulo que funcione no puede insertarse en un núcleo que el contenedor no posee.

Cuando aparezca el dispositivo, reinicie el servicio y confirme la interfaz antes de probar el tráfico. Ver tun0 muestra que el demonio ha abierto el dispositivo. Todavía no dice nada sobre el reenvío, las reglas de firewall o las rutas que reciben los clientes.

Son preguntas separadas con pruebas separadas. Un dispositivo ausente es un fallo de requisito previo; un túnel que existe pero no transporta nada es un fallo de política.