OpenVPN pe un VPS: niciun dispozitiv /dev/net/tun de deschis

Prima pornire eșuează cu un mesaj despre /dev/net/tun sau un dispozitiv TUN/TAP care nu poate fi deschis. Certificatele nu au fost încă citite, deci nimic din profil nu e vinovat. Daemonul cere kernelului un obiect pe care acest guest nu îl are.

Acest obiect este un dispozitiv de caractere susținut de modulul tun. Dacă îl poți crea depinde de cine deține kernelul.

Ce cere daemonul kernelului

OpenVPN deschide /dev/net/tun și cere driverului o interfață. Driverul este modulul tun, iar nodul dispozitivului este mânerul prin care spațiul utilizator ajunge la el. Dacă modulul nu este încărcat, nodul poate lipsi sau deschiderea poate eșua. Niciuna dintre stări nu se repară editând server.conf.

Citește eroarea mai întâi ca o întrebare despre platformă. O eroare de configurare apare după ce dispozitivul se deschide, nu înainte.

VM sau guest cu kernel partajat

Pe KVM, Xen sau altă mașină virtuală completă, kernelul este sub controlul tău. Poți încărca module și crea nodul. Pe OpenVZ, Virtuozzo sau un container în stil LXC, guestul partajează kernelul gazdei, așa că root din interior nu poate încărca un modul pe care gazda nu l-a încărcat.

Aceeași eroare are deci doi proprietari foarte diferiți. În primul caz o poți repara din interiorul instanței. În al doilea ceri gazdei, sau furnizorului, să expună ceva.

Rulează ls -l /dev/net/tun, lsmod | grep tun și ip -brief link show înainte de a decide în ce caz te afli.

Pe un VM, încarcă modulul la pornire

Pe o mașină virtuală, modprobe tun creează de obicei nodul dispozitivului. Verifică dacă apare, apoi fă încărcarea permanentă prin configurația de module a distribuției, în loc să te bazezi pe o comandă tastată o dată. Un nod care dispare după repornire devine același tichet luna viitoare.

Verifică și dacă kernelul pe care l-ai pornit are modulul deloc. Un kernel de furnizor redus poate să nu îl aibă.

Dacă nodul există dar deschiderea tot eșuează, permisiunile și numerele major/minor ale dispozitivului sunt următorii suspecți. Sunt reparații locale, nu cereri către furnizor.

Într-un container, dispozitivul aparține gazdei

Într-un container, dispozitivul și capabilitatea sunt două cerințe separate. Runtime-ul trebuie să lase /dev/net/tun să treacă, iar containerul are nevoie de capabilitatea de rețea pentru a crea o interfață. Un runtime rootless care nu acordă niciuna va continua să producă aceeași eroare de deschidere, oricum ar fi scris profilul. Multe gazde OpenVZ oferă un comutator TUN/TAP în panoul clientului, iar activarea lui plus o repornire este adesea întreaga soluție.

Pune furnizorului două întrebări precise: modulul tun este încărcat pe gazdă și dispozitivul este disponibil în interiorul acestei instanțe? Un tichet vag primește un răspuns vag.

De ce reconstruirea modulului ajută rareori

Construirea unui modul în interiorul guestului ajută rareori. Compilarea are nevoie de configurația exactă a kernelului care rulează, iar /proc/config.gz este opțional și lipsește adesea pe imaginile minime. Chiar și un modul funcțional nu poate fi inserat într-un kernel pe care containerul nu îl deține.

După ce dispozitivul apare, repornește serviciul și confirmă interfața înainte de a testa trafic. Vederea tun0 arată că daemonul a deschis dispozitivul. Nu spune încă nimic despre forwardare, reguli de firewall sau rutele pe care le primesc clienții.

Sunt întrebări separate cu dovezi separate. Un dispozitiv lipsă este o eșec al precondiției; un tunel care există dar nu transportă nimic este un eșec de politică.