/dev/net/tun ausente con tun cargado: reparar o nodo de dispositivo

OpenVPN detense cunha queixa errno 2 sobre /dev/net/tun mentres que lsmod enumera sen problema o módulo tun. Ambos os feitos son certos á vez. O módulo fornece un controlador, e a ruta que abre o cliente é un nodo de dispositivo que algo máis ten que crear. Tratalos como un só obxecto é a razón pola que a reparación obvia de recargar o módulo non cambia absolutamente nada.

Dous obxectos, dous propietarios distintos

Un módulo do núcleo e un nodo de dispositivo son obxectos independentes con ciclos de vida independentes. Cargar o módulo rexistra un controlador, e nun sistema con devtmpfs o núcleo pide que se cree o nodo correspondente. Nun sistema sen devtmpfs nada crea nada, e o controlador queda alí sen ningunha ruta que apunte a el. O módulo pode estar cargado, san e completamente inalcanzable a través do sistema de ficheiros no mesmo momento.

Por iso o texto do erro e a lista de módulos non se contradín. O cliente abre unha ruta, a ruta non existe, e o núcleo devolve ENOENT antes de que o controlador tun sexa consultado sequera. Recargar o módulo non pode reparar unha ruta ausente, e crear a ruta non pode reparar un controlador ausente.

lsmod | grep -w tun
stat -c "%F %t:%T" /dev/net/tun
grep " /dev " /proc/mounts

devtmpfs fronte a un mknod explícito

Normalmente dous mecanismos crean ese nodo, e saber cal se supón que é o responsable dille que reparar. devtmpfs fai que o núcleo cree nodos de dispositivo nunha instancia montada, e udev aplica propiedade e permisos por riba deles. Un mknod explícito é a ruta manual para imaxes e espazos de nomes onde ningún dos dous se executa ao arrincar.

Compare resultados en lugar de intencións. Se devtmpfs está montado en /dev e o nodo segue ausente, o controlador non é o que vostede supón, ou algo eliminou o nodo despois do arrinque. Se /dev é un directorio normal dentro dun rootfs desempaquetado, non existe ningún mecanismo automático e quen constrúe a imaxe ten que crear o nodo.

stat -c "%F major=%t minor=%T" /dev/net/tun
# expect: character special file major=a minor=c8

Onde non se executa ningún dos dous mecanismos, o nodo ten que facerse a man, e a orde importa. Cree primeiro o directorio pai, porque mknod non pode inventalo, logo o dispositivo de caracteres, logo un modo que o deixe escribible só para root. Recargue o módulo antes de crear o nodo, e elimine unha ruta existente só despois de que ls mostrase que é un directorio e non un dispositivo.

sudo modprobe tun
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun
ls -l /dev/net/tun

O tipo que informa stat é o discriminante máis rápido, e un directorio nesa ruta é a sorpresa máis habitual en imaxes mínimas. Un mkdir benintencionado nun Dockerfile deixa exactamente iso, e ningunha cantidade de carga de módulos substitúe un directorio por un dispositivo de caracteres. Major 10 con minor 200 é o par rexistrado para tun, expresado en hexadecimal como a e c8.

Catro rastros, catro causas

Catro causas explican case todos os casos, e cada unha deixa un rastro distinto nos rexistros. Comece polo contorno de arrinque. As imaxes sen disco, as placas integradas e as etapas de initramfs a miúdo non montan nin devtmpfs nin un /devxestionado por udev, así que ningún proceso escribe nunca o nodo. Despois lea as opcións de montaxe do que aloxe /dev, porque nodev permite que a ruta exista mentres se nega a abrila, e unha montaxe bind tomada dun anfitrión endurecido leva a bandeira sen anunciarse. Unha montaxe de só lectura falla antes e máis alto: mknod devolve alí EROFS, mentres que EPERM significa que ao proceso lle falta a capacidade e non que o sistema de ficheiros se protexa. Por último, un runtime de contedores co seu propio /dev tmpfs necesita que o nodo se inxecte no seu propio espazo de nomes, e o seu cgroup de dispositivos debe permitir o par major e minor.

Comprobe a capa de política antes de volver cambiar permisos. SELinux e AppArmor poden denegar unha apertura que todos os atributos do ficheiro permiten, e esa denegación aparece no rexistro de auditoría e non na saída do cliente. Un cambio de permisos que nunca aparece nunha denegación é tempo gasto na capa completamente equivocada.

sudo journalctl -k -n 20 --no-pager
sudo ausearch -m AVC -ts recent | tail -5

Demóstroo cunha interface, non cunha listaxe

Unha listaxe correcta demostra que unha ruta existe e nada máis. Abra un nodo tun san para lectura e a chamada volve cun erro, porque o dispositivo non ten semántica de lectura e non é un ficheiro normal. Ese erro é aquí o sinal de éxito, e recoñecelo evítalle perseguilo como se fose unha avaría.

head -c 1 /dev/net/tun
head: error reading '/dev/net/tun': File descriptor in bad state

A proba decisiva crea unha interface, porque exercita o controlador, o nodo e os seus privilexios nun só paso. Se a adición ten éxito e a ligazón aparece, os tres funcionan. Cando falla, o errno separa as causas: ENOENT significa que non hai ningún nodo utilizábel, EPERM apunta á capacidade, ás bandeiras de montaxe ou á política, e EBUSY significa que outro proceso xa posúe a interface.

sudo ip tuntap add dev tun7 mode tun
ip -brief link show tun7
sudo ip tuntap del dev tun7 mode tun

Execute esa proba no contexto que realmente falla, porque unha unidade de servizo, un contedor ou unha tarefa programada poden levar un conxunto de capacidades distinto do do seu intérprete de ordes de inicio de sesión. Unha proba que pasa no contexto equivocado non demostra nada sobre a que falla.

Cando o dispositivo non é o problema

Se a proba de interface ten éxito e o cliente segue fallando, o problema restante é o perfil, o contexto do servizo ou a ruta, e o dispositivo está ben. Ese é o momento de deixar de editar nodos de dispositivo, porque máis cambios só engaden distancia respecto a un sistema que funciona.

Execute as mesmas cinco comprobacións cada vez en lugar de inventar unha nova: está o módulo cargado sen un módulo rival, é a ruta un dispositivo de caracteres co major e o minor correctos, están limpas as opcións de montaxe, leva o contexto do proceso a capacidade, e hai unha denegación de política na marca de tempo do fallo. Unha avaría que sobrevive ás cinco non é un problema de dispositivo, diga o que diga a mensaxe.