OpenVPN sur VPS: mankas aparato /dev/net/tun por malfermi

La unua starto malsukcesas kun mesaĝo pri /dev/net/tun aŭ TUN/TAP-aparato, kiun oni ne povas malfermi. Atestiloj ankoraŭ ne estas legitaj, do nenio en la profilo estas suspektata. La demono petas de la kerno objekton, kiun ĉi tiu gasto ne havas.

Tiu objekto estas signa aparato subtenata de la modulo tun. Ĉu vi povas krei ĝin dependas de tio, kiu posedas la kernon.

Kion la demono petas de la kerno

OpenVPN malfermas /dev/net/tun kaj petas de la pelilo interfacon. La pelilo estas la modulo tun, kaj la aparata nodo estas la tenilo, per kiu la uzantspaco atingas ĝin. Se la modulo ne estas ŝargita, la nodo povas manki aŭ la malfermo povas malsukcesi. Neniu el la du kondiĉoj ripariĝas per redaktado de server.conf.

Legu la eraron unue kiel demandon pri la platformo. Agorda eraro aperas post kiam la aparato malfermiĝis, ne antaŭe.

VM aŭ gasto kun komuna kerno

Sur KVM, Xen aŭ alia plena virtuala maŝino vi regas la kernon. Vi povas ŝargi modulojn kaj krei la nodon. Sur OpenVZ, Virtuozzo aŭ ujo laŭ stilo LXC la gasto dividas la kernon de la gastiganto, do root ene ne povas ŝargi modulon, kiun la gastiganto ne ŝargis.

La sama malsukceso do havas du tre malsamajn posedantojn. En la unua kazo vi povas ripari ĝin el la interno de la instanco. En la dua vi petas de la gastiganto aŭ de la provizanto malkaŝi ion.

Rulu ls -l /dev/net/tun, lsmod | grep tun kaj ip -brief link show antaŭ ol decidi, en kiu kazo vi estas.

Sur VM, ŝargu la modulon ĉe starto

Sur virtuala maŝino modprobe tun kutime kreas la aparatan nodon. Kontrolu, ke ĝi aperas, poste daŭrigu la ŝargon per la modula agordo de la distribuo anstataŭ fidi komandon tajpitan unufoje. Nodo, kiu malaperas post restarto, fariĝas la sama bileto venontmonate.

Kontrolu ankaŭ, ĉu la kerno, kiun vi startigis, entute havas la modulon. Senigita kerno de provizanto povas manki ĝin.

Se la nodo ekzistas sed la malfermo ankoraŭ malsukcesas, permesoj kaj la major/minor-nombroj de la aparato estas la sekvaj suspektatoj. Tiuj estas lokaj riparoj, ne petoj al la provizanto.

En ujo, la gastiganto posedas la aparaton

En ujo, la aparato kaj la kapablo estas du apartaj postuloj. La runtime devas trapasi /dev/net/tun, kaj la ujo bezonas la retan kapablon por krei interfacon. Senradika runtime, kiu donas nek unu nek la alian, daŭre produktos la saman malferman eraron kiel ajn la profilo estas skribita. Multaj OpenVZ-gastigantoj montras TUN/TAP-ŝaltilon en la klienta panelo, kaj ŝalti ĝin plus restarto ofte estas la tuta solvo.

Demandu la provizanton du precizajn demandojn: ĉu la modulo tun estas ŝargita sur la gastiganto, kaj ĉu la aparato estas disponebla ene de ĉi tiu instanco? Vaganta bileto ricevas vagan respondon.

Kial rekonstrui la modulon malofte helpas

Konstrui modulon ene de la gasto malofte helpas. Kompilado bezonas la agordon de la ĝuste kuranta kerno, kaj /proc/config.gz estas laŭvola kaj ofte forestas en minimumaj bildoj. Eĉ funkcianta modulo ne povas esti enmetita en kernon, kiun la ujo ne posedas.

Post kiam la aparato aperas, restartigu la servon kaj konfirmu la interfacon antaŭ ol testi trafikon. Vidi tun0 montras, ke la demono malfermis la aparaton. Ĝi ankoraŭ diras nenion pri plusendado, firewall-reguloj aŭ la itineroj, kiujn klientoj ricevas.

Tiuj estas apartaj demandoj kun apartaj pruvoj. Mankanta aparato estas malsukceso de antaŭkondiĉo; tunelo, kiu ekzistas sed portas nenion, estas malsukceso de politiko.