OpenVPN su un VPS: nessun dispositivo /dev/net/tun da aprire

Il primo avvio fallisce con un messaggio su /dev/net/tun o su un dispositivo TUN/TAP che non può essere aperto. I certificati non sono ancora stati letti, quindi nulla nel profilo è implicato. Il demone sta chiedendo al kernel un oggetto che questo guest non possiede.

Quell'oggetto è un dispositivo a caratteri fornito dal modulo tun. Se puoi crearlo dipende da chi possiede il kernel.

Cosa chiede il demone al kernel

OpenVPN apre /dev/net/tun e chiede al driver un'interfaccia. Il driver è il modulo tun, e il nodo del dispositivo è il riferimento che lo spazio utente usa per raggiungerlo. Se il modulo non è caricato, il nodo può mancare o l'apertura può fallire. Nessuna delle due condizioni si risolve modificando server.conf.

Leggi l'errore prima come una domanda di piattaforma. Un errore di configurazione compare dopo che il dispositivo è stato aperto, non prima.

VM o guest a kernel condiviso

Su KVM, Xen o un'altra macchina virtuale completa il kernel è sotto il tuo controllo. Puoi caricare moduli e creare il nodo. Su OpenVZ, Virtuozzo o un container in stile LXC il guest condivide il kernel dell'host, quindi root al suo interno non può caricare un modulo che l'host non ha caricato.

Lo stesso guasto ha quindi due responsabili molto diversi. Nel primo caso puoi ripararlo dall'interno dell'istanza. Nel secondo stai chiedendo all'host, o al provider, di esporre qualcosa.

Esegui ls -l /dev/net/tun, lsmod | grep tun e ip -brief link show prima di decidere in quale caso ti trovi.

Su una VM, carica il modulo all'avvio

Su una macchina virtuale, modprobe tun di solito crea il nodo del dispositivo. Verifica che compaia, poi rendi permanente il caricamento tramite la configurazione dei moduli della distribuzione invece di affidarti a un comando digitato una volta. Un nodo che svanisce dopo un riavvio diventa lo stesso ticket il mese prossimo.

Controlla anche che il kernel avviato abbia il modulo disponibile. Un kernel del fornitore alleggerito può non averlo.

Se il nodo esiste ma l'apertura fallisce ancora, i permessi e i numeri major/minor del dispositivo sono i sospetti successivi. Sono correzioni locali, non richieste al provider.

In un container il dispositivo appartiene all'host

In un container il dispositivo e la capability sono due requisiti separati. Il runtime deve passare /dev/net/tun e il container ha bisogno della capability di rete per creare un'interfaccia. Un runtime rootless che non concede nessuna delle due continuerà a produrre lo stesso errore di apertura, per quanto bene sia scritto il profilo. Molti host OpenVZ espongono un interruttore TUN/TAP nel pannello cliente, e attivarlo più un riavvio è spesso tutta la soluzione.

Fai al provider due domande precise: il modulo tun è caricato sull'host e il dispositivo è disponibile dentro questa istanza? Un ticket vago riceve una risposta vaga.

Perché ricompilare il modulo aiuta di rado

Compilare un modulo dentro il guest aiuta di rado. La compilazione richiede la configurazione esatta del kernel in esecuzione, e /proc/config.gz è facoltativo e spesso assente sulle immagini minime. Anche un modulo funzionante non può essere inserito in un kernel che il container non possiede.

Dopo che il dispositivo compare, riavvia il servizio e verifica l'interfaccia prima di provare il traffico. Vedere tun0 mostra che il demone ha aperto il dispositivo. Non dice ancora nulla su forwarding, regole del firewall o rotte che ricevono i client.

Sono domande separate con prove separate. Un dispositivo mancante è un fallimento dei prerequisiti; un tunnel che esiste ma non trasporta nulla è un fallimento di policy.