OpenVPN VPS-ում. /dev/net/tun սարք չկա բացելու համար

Առաջին մեկնարկը ձախողվում է /dev/net/tun-ի կամ չբացվող TUN/TAP սարքի մասին հաղորդագրությամբ։ Վկայագրերը դեռ չեն կարդացվել, ուստի պրոֆիլում ոչինչ կասկածելի չէ։ Դեմոնը միջուկից պահանջում է օբյեկտ, որը այս հյուրը չունի։

Այդ օբյեկտը նիշային սարք է, որն ապահովում է tun մոդուլը։ Կարող եք այն ստեղծել, թե ոչ, կախված է նրանից, թե ով է տիրում միջուկին։

Ինչ է դեմոնը պահանջում միջուկից

OpenVPN-ը բացում է /dev/net/tun-ը և վարորդից ինտերֆեյս է պահանջում։ Վարորդը tun մոդուլն է, իսկ սարքի հանգույցը այն բռնակն է, որով օգտագործողի տարածությունը հասնում է դրան։ Եթե մոդուլը բեռնված չէ, հանգույցը կարող է բացակայել կամ բացումը կարող է ձախողվել։ Ոչ մի պայման չի ուղղվում server.conf-ը խմբագրելով։

Սխալը նախ կարդացեք որպես հարթակի հարց։ Կազմաձևի սխալը հայտնվում է սարքի բացումից հետո, ոչ առաջ։

VM կամ ընդհանուր միջուկով հյուր

KVM-ի, Xen-ի կամ այլ լիարժեք վիրտուալ մեքենայի վրա միջուկը դուք եք կառավարում։ Կարող եք բեռնել մոդուլներ և ստեղծել հանգույցը։ OpenVZ-ի, Virtuozzo-ի կամ LXC ոճի կոնտեյների վրա հյուրը կիսում է հոսթի միջուկը, ուստի ներսի root-ը չի կարող բեռնել մոդուլ, որը հոսթը չի բեռնել։

Այսպիսով, նույն ձախողումն ունի երկու շատ տարբեր սեփականատեր։ Առաջին դեպքում կարող եք ուղղել այն ինստանսի ներսից։ Երկրորդում դուք խնդրում եք հոսթից կամ մատակարարից ինչ-որ բան բացահայտել։

Նախքան որոշելը, թե որ դեպքում եք, գործարկեք ls -l /dev/net/tun-ը, lsmod | grep tun-ը և ip -brief link show-ը։

VM-ի վրա մոդուլը բեռնեք բուտի ժամանակ

Վիրտուալ մեքենայի վրա modprobe tun-ը սովորաբար ստեղծում է սարքի հանգույցը։ Ստուգեք, որ այն հայտնվում է, ապա բեռնումը դարձրեք մշտական դիստրիբյուտիվի մոդուլների կազմաձևի միջոցով՝ մեկ անգամ մուտքագրված հրամանին ապավինելու փոխարեն։ Վերագործարկումից հետո անհետացող հանգույցը հաջորդ ամիս դառնում է նույն տոմսը։

Ստուգեք նաև, թե արդյոք ձեր բուտած միջուկն ընդհանրապես ունի մոդուլը։ Կրճատված մատակարարի միջուկը կարող է այն չունենալ։

Եթե հանգույցը կա, բայց բացումը դեռ ձախողվում է, հաջորդ կասկածյալներն են թույլտվությունները և սարքի major/minor համարները։ Դրանք տեղական ուղղումներ են, ոչ թե մատակարարին ուղղված հարցումներ։

Կոնտեյներում սարքը պատկանում է հոսթին

Կոնտեյներում սարքը և կարողությունը երկու առանձին պահանջ են։ Runtime-ը պետք է անցկացնի /dev/net/tun-ը, և կոնտեյներին անհրաժեշտ է ցանցային կարողություն ինտերֆեյս ստեղծելու համար։ Առանց root-ի runtime-ը, որը չի տալիս ոչ մեկը, կշարունակի առաջացնել նույն բացման սխալը, ինչպես էլ գրված լինի պրոֆիլը։ OpenVZ-ի շատ հոսթեր հաճախորդի վահանակում TUN/TAP անջատիչ են ցուցադրում, և այն միացնելը գումարած վերագործարկումը հաճախ ամբողջ լուծումն է։

Մատակարարին տվեք երկու ճշգրիտ հարց. արդյոք tun մոդուլը բեռնված է հոսթի վրա, և արդյոք սարքը հասանելի է այս ինստանսի ներսում։ Անորոշ տոմսը ստանում է անորոշ պատասխան։

Ինչու մոդուլի վերակառուցումը հազվադեպ է օգնում

Հյուրի ներսում մոդուլ կառուցելը հազվադեպ է օգնում։ Կոմպիլյացիան պահանջում է հենց գործող միջուկի կազմաձևը, իսկ /proc/config.gz-ը կամընտիր է և հաճախ բացակայում է նվազագույն պատկերներում։ Նույնիսկ աշխատող մոդուլը հնարավոր չէ մտցնել միջուկ, որը կոնտեյներինը չէ։

Սարքի հայտնվելուց հետո վերագործարկեք ծառայությունը և հաստատեք ինտերֆեյսը նախքան երթևեկությունը փորձարկելը։ tun0-ը տեսնելը ցույց է տալիս, որ դեմոնը բացել է սարքը։ Դեռ ոչինչ չի ասում փոխանցման, firewall-ի կանոնների կամ հաճախորդների ստացած երթուղիների մասին։

Դրանք առանձին հարցեր են առանձին ապացույցներով։ Բացակայող սարքը նախապայմանի ձախողում է, իսկ գոյություն ունեցող, բայց ոչինչ չտեղափոխող թունելը քաղաքականության ձախողում է։