OpenVPN op in VPS: gjin /dev/net/tun-apparaat om te iepenjen

De earste start mislearret mei in berjocht oer /dev/net/tun of in TUN/TAP-apparaat dat net iepene wurde kin. Sertifikaten binne noch net lêzen, dus neat yn it profyl is fertocht. De daemon freget de kearn om in objekt dat dizze gast net hat.

Dat objekt is in tekenapparaat dat troch de tun-module stipe wurdt. Oft jo it meitsje kinne, hinget ôf fan wa't de kearn hat.

Wat de daemon de kearn freget

OpenVPN iepenet /dev/net/tun en freget de bestjoerder om in ynterface. De bestjoerder is de tun-module, en it apparaatknooppunt is it hânsel dat brûkersromte brûkt om der te kommen. As de module net laden is, kin it knooppunt ûntbrekke of kin it iepenjen mislearje. Gjin fan beide tastannen wurdt reparearre troch server.conf te bewurkjen.

Lês de flater earst as in platfoarmfraach. In konfiguraasjeflater ferskynt neidat it apparaat iepene is, net earder.

VM of gast mei dielde kearn

Op KVM, Xen of in oare folsleine firtuele masine behearskje jo de kearn. Jo kinne modules lade en it knooppunt meitsje. Op OpenVZ, Virtuozzo of in kontener yn LXC-styl dielt de gast de kearn fan de host, dus root binnenyn kin gjin module lade dy't de host net laden hat.

Deselde mislearring hat dus twa hiel ferskillende eigners. Yn it earste gefal kinne jo it fan binnen de ynstânsje reparearje. Yn it twadde freegje jo de host, of de oanbieder, om eat bleat te lizzen.

Fier ls -l /dev/net/tun, lsmod | grep tun en ip -brief link show út foardat jo beslute yn hokker gefal jo binne.

Op in VM, laad de module by it opstarten

Op in firtuele masine makket modprobe tun meastal it apparaatknooppunt. Kontrolearje oft it ferskynt, en meitsje it laden dan duorsum fia de moduleskonfiguraasje fan de distribúsje ynstee fan te fertrouwen op in kommando dat ien kear typt is. In knooppunt dat nei in werstart ferdwynt, wurdt folgjende moanne deselde kaart.

Kontrolearje ek oft de kearn dy't jo boot hawwe de module wol hat. In útklaaide leveransierskearn kin him misse.

As it knooppunt bestiet mar it iepenjen mislearret noch, binne rjochten en de major/minor-nûmers fan it apparaat de folgjende fertochten. Dat binne lokale reparearjes, gjin fersiken oan de oanbieder.

Yn in kontener is de host eigner fan it apparaat

Yn in kontener binne it apparaat en de kapasiteit twa aparte easken. De runtime moat /dev/net/tun trochlitte, en de kontener hat de netwurk kapasiteit nedich om in ynterface te meitsjen. In rootless runtime dy't gjin fan beide jout, bliuwt deselde iepeningsflater produsearjen hoe't it profyl ek skreaun is. In protte OpenVZ-hosts biede in TUN/TAP-skeakelder yn it klantpaniel, en it oansette dêrfan plus in werstart is faak de hiele oplossing.

Freegje de oanbieder twa krekte fragen: is de tun-module op de host laden, en is it apparaat binnen dizze ynstânsje beskikber? In ûndúdlik kaartsje krijt in ûndúdlik antwurd.

Wêrom't it werbouwen fan de module selden helpt

In module yn 'e gast bouwe helpt selden. Kompilaasje hat de konfiguraasje fan 'e krekt rinnende kearn nedich, en /proc/config.gz is opsjoneel en ûntbrekt faak op minimale bylden. Sels in wurkjende module kin net yn in kearn pleatst wurde dy't de kontener net hat.

Nei't it apparaat ferskynt, werstart de tsjinst en befêstigje de ynterface foardat jo ferkear test. tun0 sjen lit dat de daemon it apparaat iepene hat. It seit noch neat oer trochstjoeren, firewall-regels of de rûtes dy't kliïnten krije.

Dat binne aparte fragen mei apart bewiis. In ûntbrekkend apparaat is in mislearre betingst; in tunnel dy't bestiet mar neat draacht is in beliedsflater.