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, ხოლო კონტეინერს ინტერფეისის შესაქმნელად ქსელის შესაძლებლობა სჭირდება. Rootless runtime, რომელიც არც ერთს არ იძლევა, იგივე გახსნის შეცდომას განაგრძობს, როგორც არ უნდა იყოს პროფილი დაწერილი. ბევრი OpenVZ ჰოსტი მომხმარებლის პანელში TUN/TAP გადამრთველს აჩვენებს და მისი ჩართვა გადატვირთვასთან ერთად ხშირად მთელი გადაწყვეტაა.

პროვაიდერს ორი ზუსტი კითხვა დაუსვით: ჩატვირთულია თუ არა tun მოდული ჰოსტზე და ხელმისაწვდომია თუ არა მოწყობილობა ამ ინსტანციის შიგნით? ბუნდოვანი ტიკეტი ბუნდოვან პასუხს იღებს.

რატომ იშვიათად ეხმარება მოდულის ხელახლა აწყობა

სტუმრის შიგნით მოდულის აწყობა იშვიათად ეხმარება. კომპილაციას სჭირდება ზუსტად გაშვებული ბირთვის კონფიგურაცია, ხოლო /proc/config.gz არასავალდებულოა და მინიმალურ იმიჯებზე ხშირად არ არსებობს. მუშა მოდულიც კი ვერ ჩაემატება ბირთვში, რომელსაც კონტეინერი არ ფლობს.

მოწყობილობის გამოჩენის შემდეგ გადატვირთეთ სერვისი და ტრაფიკის შემოწმებამდე დაადასტურეთ ინტერფეისი. tun0-ის დანახვა იმას გვიჩვენებს, რომ დემონმა მოწყობილობა გახსნა. ის ჯერ არაფერს ამბობს გადამისამართებაზე, firewall წესებზე ან იმ მარშრუტებზე, რომლებსაც კლიენტები იღებენ.

ეს ცალკეული კითხვებია ცალკეული მტკიცებულებებით. დაკარგული მოწყობილობა წინაპირობის მარცხია; გვირაბი, რომელიც არსებობს, მაგრამ არაფერს გადააქვს, პოლიტიკის მარცხია.