OpenVPN sa isang VPS: walang /dev/net/tun na device na bubuksan

Nabibigo ang unang pag-start na may mensahe tungkol sa /dev/net/tun o isang TUN/TAP device na hindi mabuksan. Hindi pa nababasa ang mga certificate, kaya walang dapat sisihin sa profile. Humihingi ang daemon sa kernel ng object na wala ang guest na ito.

Ang object na iyon ay isang character device na sinusuportahan ng tun module. Kung maaari mong likhain ito ay depende sa kung sino ang may-ari ng kernel.

Ano ang hinihingi ng daemon sa kernel

OpenVPN ay nagbubukas ng /dev/net/tun at humihingi sa driver ng interface. Ang driver ay ang tun module, at ang device node ay ang hawakan na ginagamit ng userspace upang maabot ito. Kung hindi naka-load ang module, maaaring wala ang node o maaaring mabigo ang pagbukas. Wala sa mga kalagayan ang naaayos sa pamamagitan ng pag-edit ng server.conf.

Basahin muna ang error na ito bilang tanong tungkol sa platform. Lumilitaw ang error sa configuration pagkatapos mabuksan ang device, hindi bago.

VM o guest na may shared kernel

Sa KVM, Xen o iba pang buong virtual machine, ikaw ang may kontrol sa kernel. Maaari kang mag-load ng mga module at lumikha ng node. Sa OpenVZ, Virtuozzo o container na LXC-style, ibinabahagi ng guest ang kernel ng host, kaya ang root sa loob nito ay hindi makakapag-load ng module na hindi na-load ng host.

Kaya ang parehong pagkabigo ay may dalawang lubos na magkaibang may-ari. Sa unang kaso, maaari mong ayusin ito mula sa loob ng instance. Sa pangalawa, hinihiling mo sa host, o sa provider, na ilantad ang isang bagay.

Patakbuhin ang ls -l /dev/net/tun, lsmod | grep tun at ip -brief link show bago magpasya kung aling kaso ka.

Sa isang VM, i-load ang module sa boot

Sa isang virtual machine, karaniwang lumilikha ang modprobe tun ng device node. Tiyakin na lumitaw ito, pagkatapos ay gawing permanente ang pag-load sa pamamagitan ng module configuration ng distribution sa halip na umasa sa isang command na na-type nang isang beses. Ang node na nawawala pagkatapos ng reboot ay nagiging parehong ticket sa susunod na buwan.

Tiyakin din kung ang kernel na na-boot mo ay may module na ito. Ang pinutol na vendor kernel ay maaaring wala nito.

Kung umiiral ang node ngunit nabibigo pa rin ang pagbukas, ang susunod na pinaghihinalaan ay ang mga pahintulot at ang major/minor na numero ng device. Iyon ay mga lokal na pag-aayos, hindi mga kahilingan sa provider.

Sa isang container, pag-aari ng host ang device

Sa isang container, ang device at ang capability ay dalawang magkahiwalay na pangangailangan. Dapat ipasa ng runtime ang /dev/net/tun, at kailangan ng container ang network capability upang lumikha ng interface. Ang rootless runtime na hindi nagbibigay ng alinman sa dalawa ay patuloy na gagawa ng parehong error sa pagbukas, gaano man isinulat ang profile. Maraming OpenVZ host ang nag-aalok ng TUN/TAP toggle sa customer panel, at ang pag-on nito kasama ng restart ay madalas ang buong solusyon.

Tanungin ang provider ng dalawang tiyak na tanong: naka-load ba ang tun module sa host, at available ba ang device sa loob ng instance na ito? Ang malabong ticket ay nakakakuha ng malabong sagot.

Bakit bihirang makatulong ang muling pagbuo ng module

Ang pagbuo ng module sa loob ng guest ay bihirang makatulong. Kailangan ng compilation ang configuration ng eksaktong tumatakbong kernel, at ang /proc/config.gz ay opsyonal at madalas na wala sa minimal na mga image. Kahit ang gumaganang module ay hindi maisisingit sa kernel na hindi pag-aari ng container.

Kapag lumitaw ang device, i-restart ang serbisyo at kumpirmahin ang interface bago subukan ang traffic. Ang makita ang tun0 ay nagpapakita na binuksan ng daemon ang device. Wala pa itong sinasabi tungkol sa forwarding, firewall rules o mga ruta na natatanggap ng mga client.

Ito ay magkahiwalay na tanong na may magkahiwalay na ebidensya. Ang nawawalang device ay pagkabigo ng paunang kundisyon; ang tunnel na umiiral ngunit walang dinadala ay pagkabigo ng patakaran.