OpenVPN på ein VPS: inga /dev/net/tun-eining å opne

Første oppstart feilar med ei melding om /dev/net/tun eller ei TUN/TAP-eining som ikkje kan opnast. Sertifikata er enno ikkje lesne, så ingenting i profilen er mistenkt. Tenaren ber kjernen om eit objekt som denne gjesten ikkje har.

Det objektet er ei teikneining som vert støtta av tun-modulen. Om du kan lage ho, kjem an på kven som eig kjernen.

Kva tenaren ber kjernen om

OpenVPN opnar /dev/net/tun og ber drivaren om eit grensesnitt. Drivaren er tun-modulen, og einingsnoden er handtaket brukarrommet nyttar for å nå ho. Viss modulen ikkje er lasta, kan noden mangle eller opninga kan misse. Ingen av tilstandane vert retta ved å endre server.conf.

Les feilen først som eit spørsmål om plattforma. Ein konfigurasjonsfeil syner seg etter at eininga er opna, ikkje før.

VM eller gjest med delt kjerne

På KVM, Xen eller ei anna full virtuell maskin styrer du kjernen. Du kan laste modular og lage noden. På OpenVZ, Virtuozzo eller ein container i LXC-stil deler gjesten kjernen til verten, så root inne i han kan ikkje laste ein modul verten ikkje har lasta.

Den same feilen har difor to svært ulike eigarar. I det første tilfellet kan du rette han frå innsida av instansen. I det andre ber du verten, eller leverandøren, om å eksponere noko.

Køyr ls -l /dev/net/tun, lsmod | grep tun og ip -brief link show før du avgjer kva tilfelle du er i.

På ein VM, last modulen ved oppstart

På ei virtuell maskin lagar modprobe tun vanlegvis eininga. Kontroller at ho dukkar opp, og gjer deretter lastinga varig gjennom modulkonfigurasjonen til distribusjonen i staden for å stole på ein kommando skriven éin gong. Ein node som forsvinn etter omstart vert same saka neste månad.

Kontroller òg at kjernen du starta har modulen i det heile. Ein nedskalert leverandørkjerne kan mangle han.

Viss noden finst men opninga framleis feilar, er løyve og major/minor-numra til eininga dei neste mistenkte. Det er lokale rettingar, ikkje førespurnader til leverandøren.

I ein container eig verten eininga

I ein container er eininga og kapabiliteten to separate krav. Runtime må sleppe /dev/net/tun gjennom, og containeren treng nettverkskapabiliteten for å lage eit grensesnitt. Ein rootless runtime som ikkje gjev nokon av delane vil halde fram med å produsere den same opnefeilen uansett korleis profilen er skriven. Mange OpenVZ-vertar tilbyr ein TUN/TAP-brytar i kundepanelet, og å slå han på pluss ein omstart er ofte heile løysinga.

Still leverandøren to presise spørsmål: er tun-modulen lasta på verten, og er eininga tilgjengeleg inne i denne instansen? Ei vag sak får eit vagt svar.

Kvifor det sjeldan hjelper å byggje modulen på nytt

Å byggje ein modul inne i gjesten hjelper sjeldan. Kompilering krev konfigurasjonen til nøyaktig den køyrande kjernen, og /proc/config.gz er valfri og manglar ofte på minimale avbilete. Sjølv ein fungerande modul kan ikkje setjast inn i ein kjerne som containeren ikkje eig.

Når eininga dukkar opp, start tenesta på nytt og stadfest grensesnittet før du testar trafikk. Å sjå tun0 viser at tenaren opna eininga. Det seier enno ingenting om vidaresending, brannmurreglar eller rutene klientane får.

Det er separate spørsmål med separate prov. Ei manglande eining er ein føresetnadsfeil; ein tunnel som finst men ikkje fraktar noko er ein politikkfeil.