OpenVPN nun VPS: non hai dispositivo /dev/net/tun que abrir

O primeiro arranque falla cunha mensaxe sobre /dev/net/tun ou un dispositivo TUN/TAP que non se pode abrir. Os certificados aínda non se leron, así que nada do perfil está implicado. O daemon pide ao núcleo un obxecto que este convidado non ten.

Ese obxecto é un dispositivo de caracteres soportado polo módulo tun. Que poida crealo depende de quen posúe o núcleo.

Que pide o daemon ao núcleo

OpenVPN abre /dev/net/tun e pide ao controlador unha interface. O controlador é o módulo tun, e o nodo do dispositivo é o manexador que o espazo de usuario usa para alcanzalo. Se o módulo non está cargado, o nodo pode faltar ou a apertura pode fallar. Ningunha das dúas condicións se corrixe editando server.conf.

Lea o erro primeiro como unha pregunta de plataforma. Un erro de configuración aparece despois de que se abra o dispositivo, non antes.

VM ou convidado con núcleo compartido

En KVM, Xen ou outra máquina virtual completa vostede controla o núcleo. Pode cargar módulos e crear o nodo. En OpenVZ, Virtuozzo ou un contedor ao estilo LXC o convidado comparte o núcleo do anfitrión, así que root dentro non pode cargar un módulo que o anfitrión non cargou.

Por tanto, o mesmo fallo ten dous propietarios moi distintos. No primeiro caso pode arranxalo desde dentro da instancia. No segundo está pedindo ao anfitrión, ou ao provedor, que expoña algo.

Execute ls -l /dev/net/tun, lsmod | grep tun e ip -brief link show antes de decidir en que caso está.

Nunha VM, cargue o módulo ao arrancar

Nunha máquina virtual, modprobe tun adoita crear o nodo do dispositivo. Comprobe que aparece e logo faga permanente a carga mediante a configuración de módulos da distribución en lugar de confiar nun comando escrito unha vez. Un nodo que desaparece tras un reinicio convértese no mesmo ticket o mes que vén.

Comprobe tamén que o núcleo que arrancou teña o módulo. Un núcleo de provedor recortado pode non telo.

Se o nodo existe pero a apertura segue fallando, os permisos e os números major/minor do dispositivo son os seguintes sospeitosos. Son correccións locais, non peticións ao provedor.

Nun contedor, o anfitrión posúe o dispositivo

Nun contedor, o dispositivo e a capacidade son dous requisitos separados. O runtime debe pasar /dev/net/tun, e o contedor necesita a capacidade de rede para crear unha interface. Un runtime sen root que non conceda ningunha das dúas seguirá producindo o mesmo erro de apertura por moito que se escriba o perfil. Moitos anfitrións OpenVZ mostran un conmutador TUN/TAP no panel do cliente, e activalo máis un reinicio adoita ser toda a solución.

Pregunte ao provedor dúas cuestións precisas: está cargado o módulo tun no anfitrión, e está dispoñible o dispositivo dentro desta instancia? Un ticket vago recibe unha resposta vaga.

Por que reconstruír o módulo raramente axuda

Construír un módulo dentro do convidado raramente axuda. A compilación necesita a configuración do núcleo exactamente en execución, e /proc/config.gz é opcional e a miúdo ausente en imaxes mínimas. Nin sequera un módulo que funcione se pode inserir nun núcleo que o contedor non posúe.

Cando apareza o dispositivo, reinicie o servizo e confirme a interface antes de probar o tráfico. Ver tun0 mostra que o daemon abriu o dispositivo. Aínda non di nada sobre o reenvío, as regras de firewall ou as rutas que reciben os clientes.

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