OpenVPN në një VPS: asnjë pajisje /dev/net/tun për të hapur

Nisja e parë dështon me një mesazh për /dev/net/tun ose një pajisje TUN/TAP që nuk hapet. Certifikatat nuk janë lexuar ende, kështu që asgjë në profil nuk është fajtore. Daemoni i kërkon kernelit një objekt që ky mysafir nuk e ka.

Ai objekt është një pajisje karakteresh që ofrohet nga moduli tun. Nëse mund ta krijoni varet nga kush e zotëron kernelin.

Çfarë i kërkon daemoni kernelit

OpenVPN hap /dev/net/tun dhe i kërkon drajverit një ndërfaqe. Drajveri është moduli tun, dhe nyja e pajisjes është doreza me të cilën hapësira e përdoruesit e arrin atë. Nëse moduli nuk është i ngarkuar, nyja mund të mungojë ose hapja mund të dështojë. Asnjëra prej gjendjeve nuk rregullohet duke redaktuar server.conf.

Lexojeni këtë gabim së pari si një pyetje për platformën. Një gabim konfigurimi shfaqet pasi pajisja hapet, jo para.

VM ose mysafir me kernel të përbashkët

Në KVM, Xen ose një makinë tjetër të plotë virtuale kernelin e kontrolloni ju. Mund të ngarkoni module dhe të krijoni nyjën. Në OpenVZ, Virtuozzo ose një kontejner në stilin LXC mysafiri ndan kernelin e hostit, kështu që root brenda nuk mund të ngarkojë një modul që hosti nuk e ka ngarkuar.

I njëjti dështim ka pra dy pronarë shumë të ndryshëm. Në rastin e parë mund ta rregulloni nga brenda instancës. Në të dytin po i kërkoni hostit, ose ofruesit, të ekspozojë diçka.

Ekzekutoni ls -l /dev/net/tun, lsmod | grep tun dhe ip -brief link show përpara se të vendosni në cilin rast jeni.

Në një VM, ngarkoni modulin gjatë nisjes

Në një makinë virtuale, modprobe tun zakonisht krijon nyjën e pajisjes. Kontrolloni që u shfaq, pastaj bëni ngarkimin të përhershëm përmes konfigurimit të moduleve të shpërndarjes, në vend që të mbështeteni në një komandë të shtypur një herë. Një nyje që zhduket pas rinisjes bëhet i njëjti tiket muajin tjetër.

Kontrolloni gjithashtu nëse kernelit që keni nisur e ka modulin fare. Një kernel i ofruesit i cunguar mund të mos e ketë.

Nëse nyja ekziston por hapja ende dështon, dyshuesit e radhës janë lejet dhe numrat major/minor të pajisjes. Këto janë rregullime lokale, jo kërkesa drejtuar ofruesit.

Në një kontejner, pajisja i përket hostit

Në një kontejner, pajisja dhe aftësia janë dy kërkesa të ndara. Runtime-i duhet të kalojë /dev/net/tun, dhe kontejneri ka nevojë për aftësinë e rrjetit për të krijuar një ndërfaqe. Një runtime rootless që nuk jep asnjërën do të vazhdojë të prodhojë të njëjtin gabim hapjeje, sado mirë të jetë shkruar profili. Shumë host-e OpenVZ ofrojnë një çelës TUN/TAP në panelin e klientit, dhe aktivizimi i tij plus një rinisje është shpesh e gjithë zgjidhja.

Bëjini ofruesit dy pyetje të sakta: a është i ngarkuar moduli tun në host, dhe a është pajisja e disponueshme brenda këtij instancë? Një tiket i paqartë merr një përgjigje të paqartë.

Pse rindërtimi i modulit rrallë ndihmon

Ndërtimi i një moduli brenda mysafirit rrallë ndihmon. Kompilimi kërkon konfigurimin e saktë të kernelit që po punon, dhe /proc/config.gz është opsional dhe shpesh mungon në imazhet minimale. Edhe një modul që punon nuk mund të futet në një kernel që kontejneri nuk e zotëron.

Pasi pajisja shfaqet, rinisni shërbimin dhe konfirmoni ndërfaqen përpara se të provoni trafikun. Të shohësh tun0 tregon se daemoni e hapi pajisjen. Nuk thotë ende asgjë për përcjelljen, rregullat e firewall-it ose rrugët që marrin klientët.

Këto janë pyetje të ndara me prova të ndara. Një pajisje që mungon është dështim i parakushtit; një tunel që ekziston por nuk mbart asgjë është dështim politike.