OpenVPN på en VPS: ingen /dev/net/tun-enhet å åpne

Første oppstart feiler med en melding om /dev/net/tun eller en TUN/TAP-enhet som ikke kan åpnes. Sertifikatene er ennå ikke lest, så ingenting i profilen er mistenkt. Tjeneren ber kjernen om et objekt som denne gjesten ikke har.

Det objektet er en tegnenhet som støttes av tun-modulen. Om du kan lage den, avhenger av hvem som eier kjernen.

Hva tjeneren ber kjernen om

OpenVPN åpner /dev/net/tun og ber driveren om et grensesnitt. Driveren er tun-modulen, og enhetsnoden er håndtaket brukerrommet bruker for å nå den. Hvis modulen ikke er lastet, kan noden mangle eller åpningen mislykkes. Ingen av tilstandene rettes ved å redigere server.conf.

Les feilen først som et spørsmål om plattformen. En konfigurasjonsfeil vises etter at enheten er åpnet, ikke før.

VM eller gjest med delt kjerne

På KVM, Xen eller en annen full virtuell maskin styrer du kjernen. Du kan laste moduler og lage noden. På OpenVZ, Virtuozzo eller en LXC-lignende container deler gjesten vertens kjerne, så root inne i den kan ikke laste en modul verten ikke har lastet.

Den samme feilen har derfor to svært forskjellige eiere. I det første tilfellet kan du rette den fra innsiden av instansen. I det andre ber du verten, eller leverandøren, om å eksponere noe.

Kjør ls -l /dev/net/tun, lsmod | grep tun og ip -brief link show før du avgjør hvilket tilfelle du er i.

På en VM, last modulen ved oppstart

På en virtuell maskin lager modprobe tun vanligvis enhetsnoden. Kontroller at den dukker opp, og gjør deretter lastingen varig gjennom distribusjonens modulkonfigurasjon i stedet for å stole på en kommando skrevet én gang. En node som forsvinner etter omstart blir samme sak neste måned.

Kontroller også at kjernen du startet har modulen i det hele tatt. En nedskalert leverandørkjerne kan mangle den.

Hvis noden finnes men åpningen fortsatt feiler, er tillatelser og enhetens major/minor-numre de neste mistenkte. Det er lokale rettelser, ikke forespørsler til leverandøren.

I en container eier verten enheten

I en container er enheten og kapabiliteten to separate krav. Runtime må slippe /dev/net/tun gjennom, og containeren trenger nettverkskapabiliteten for å lage et grensesnitt. En rootless runtime som ikke gir noen av delene vil fortsette å produsere den samme åpnefeilen uansett hvordan profilen er skrevet. Mange OpenVZ-verter tilbyr en TUN/TAP-bryter i kundepanelet, og å slå den på pluss en omstart er ofte hele løsningen.

Still leverandøren to presise spørsmål: er tun-modulen lastet på verten, og er enheten tilgjengelig inne i denne instansen? En vag sak får et vagt svar.

Hvorfor det sjelden hjelper å bygge modulen på nytt

Å bygge en modul inne i gjesten hjelper sjelden. Kompilering krever konfigurasjonen til nøyaktig den kjørende kjernen, og /proc/config.gz er valgfri og mangler ofte på minimale avbildninger. Selv en fungerende modul kan ikke settes inn i en kjerne containeren ikke eier.

Når enheten dukker opp, start tjenesten på nytt og bekreft grensesnittet før du tester trafikk. Å se tun0 viser at tjeneren åpnet enheten. Det sier ennå ingenting om videresending, brannmurregler eller rutene klientene får.

Det er separate spørsmål med separate bevis. En manglende enhet er en forutsetningsfeil; en tunnel som finnes men ikke frakter noe er en policyfeil.