OpenVPN en un VPS: no hi ha dispositiu /dev/net/tun per obrir

La primera arrencada falla amb un missatge sobre /dev/net/tun o un dispositiu TUN/TAP que no es pot obrir. Els certificats encara no s’han llegit, així que res del perfil no està implicat. El dimoni demana al nucli un objecte que aquest convidat no té.

Aquest objecte és un dispositiu de caràcters suportat pel mòdul tun. Que el pugueu crear depèn de qui posseeix el nucli.

Què demana el dimoni al nucli

OpenVPN obre /dev/net/tun i demana al controlador una interfície. El controlador és el mòdul tun, i el node del dispositiu és el mànec que l’espai d’usuari fa servir per arribar-hi. Si el mòdul no està carregat, el node pot faltar o l’obertura pot fallar. Cap de les dues condicions no es corregeix editant server.conf.

Llegiu l’error primer com una pregunta de plataforma. Un error de configuració apareix després que s’obri el dispositiu, no abans.

VM o convidat amb nucli compartit

En KVM, Xen o una altra màquina virtual completa vosaltres controleu el nucli. Podeu carregar mòduls i crear el node. En OpenVZ, Virtuozzo o un contenidor a l’estil LXC el convidat comparteix el nucli de l’amfitrió, així que root a dins no pot carregar un mòdul que l’amfitrió no ha carregat.

Per tant, la mateixa fallada té dos propietaris molt diferents. En el primer cas la podeu arreglar des de dins de la instància. En el segon esteu demanant a l’amfitrió, o al proveïdor, que exposi alguna cosa.

Executeu ls -l /dev/net/tun, lsmod | grep tun i ip -brief link show abans de decidir en quin cas esteu.

En una VM, carregueu el mòdul a l’arrencada

En una màquina virtual, modprobe tun normalment crea el node del dispositiu. Comproveu que aparegui i després feu la càrrega permanent mitjançant la configuració de mòduls de la distribució en lloc de dependre d’una ordre escrita una vegada. Un node que desapareix després d’un reinici es converteix en el mateix tiquet el mes que ve.

Comproveu també que el nucli que heu arrencat tingui el mòdul. Un nucli de proveïdor retallat pot no tenir-lo.

Si el node existeix però l’obertura encara falla, els permisos i els números major/minor del dispositiu són els següents sospitosos. Són correccions locals, no peticions al proveïdor.

En un contenidor, l’amfitrió posseeix el dispositiu

En un contenidor, el dispositiu i la capacitat són dos requisits separats. El runtime ha de passar /dev/net/tun, i el contenidor necessita la capacitat de xarxa per crear una interfície. Un runtime sense root que no atorgui cap de les dues seguirà produint el mateix error d’obertura per molt que s’escrigui el perfil. Molts amfitrions OpenVZ exposen un commutador TUN/TAP al panell del client, i activar-lo més un reinici sovint és tota la solució.

Pregunteu al proveïdor dues qüestions precises: el mòdul tun està carregat a l’amfitrió, i el dispositiu està disponible dins d’aquesta instància? Un tiquet vague rep una resposta vaga.

Per què reconstruir el mòdul rarament ajuda

Construir un mòdul dins del convidat rarament ajuda. La compilació necessita la configuració del nucli exactament en execució, i /proc/config.gz és opcional i sovint absent en imatges mínimes. Fins i tot un mòdul que funcioni no es pot inserir en un nucli que el contenidor no posseeix.

Quan aparegui el dispositiu, reinicieu el servei i confirmeu la interfície abans de provar el trànsit. Veure tun0 mostra que el dimoni ha obert el dispositiu. Encara no diu res sobre el reenviament, les regles de firewall o les rutes que reben els clients.

Són preguntes separades amb evidències separades. Un dispositiu absent és una fallada de prerequisit; un túnel que existeix però no porta res és una fallada de política.