LXD-ის კონტეინერი /dev/net/tun-ს ვერ ხსნის? შეამოწმეთ unix-char ჩანაწერი

LXD ჰოსტის სიმბოლურ მოწყობილობას კონტეინერისთვის ხილვადს ხდის მოწყობილობის კვანძის დამატებით და არა სტუმრისთვის მისი შექმნის სწავლებით. თუ კონტეინერში /dev/net/tun არ არის, მოწყობილობა შეიძლება ჰოსტზე იყოს და სტუმარმა მაინც ვერ გახსნას იგი. unix-char ჩანაწერი ამ გზის მმართველის მხრიდან ნახევარია და განზრახ უფრო ვიწროა, ვიდრე პრივილეგირებული კონტეინერი. ამიტომ ჰოსტის კვანძი და კონტეინერის კვანძი ცალკე შემოწმებას იმსახურებს.

მექანიზმი საკმარისად მოკლეა, რომ თვალწინ დარჩეს: LXD ჰოსტის ბილიკს წყვეტს, ინსტანსის შიგნით შესაბამის კვანძს ქმნის და მოწყობილობას კონტეინერის მოწყობილობების cgroup-ს უერთებს. შემდეგ სტუმრის პროცესს საკუთარი ნებართვა და უნარი სჭირდება, რომ კვანძი რამეზე გამოიყენოს.

რას ცვლის სინამდვილეში unix-char ჩანაწერი

unix-char მოწყობილობა LXD-ს ეუბნება, რომ ჰოსტის ერთი სიმბოლური მოწყობილობა კონტეინერის შიგნით არჩეულ ბილიკზე გამოავლინოს. ჩანაწერს სამი მნიშვნელოვანი ნაწილი აქვს: მმართველის მიერ გამოყენებული მოწყობილობის იარლიყი, ბილიკი source ჰოსტზე და path, რომელსაც სტუმარი ხედავს. მხოლოდ ბოლო ორი აღწერს თავად მოწყობილობას. რომელიმეში დაშვებული ბეჭდვითი შეცდომა კვანძს იქ ქმნის, სადაც კლიენტი არასოდეს ხსნის.

ჰოსტზე მოწყობილობა ჩვეულებრივ /dev/net/tun-ია. კონტეინერის შიგნით შეგიძლიათ იგივე ბილიკი შეინარჩუნოთ ან სხვა აირჩიოთ, მაგრამ ბილიკი უნდა შეესაბამებოდეს იმას, რასაც VPN კლიენტი ელოდება. /dev/net/tun-ის შენარჩუნება მეორე კონფიგურაციის პრობლემას თავიდან გვაცილებს, რადგან კლიენტების უმეტესობა ამ ბილიკს კითხვის გარეშე ხსნის.

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

გამოაცხადეთ მოწყობილობა ინსტანსზე და არა სტუმრის შიგნით

დაამატეთ ჩანაწერი LXD-ის ადმინისტრირების კონტექსტიდან, ინსტანსის და მოგვიანებით ამოსაცნობი იარლიყის მითითებით. vpnbox სახელის კონტეინერისთვის ბრძანება ასეთია:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

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

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

შეუსაბამეთ საკუთრება და რეჟიმი სტუმრის პროცესს

unix-char ჩანაწერს შეუძლია კონტეინერის შიგნით კვანძისთვის uid, gid და mode დააყენოს. გამოიყენეთ ისინი VPN კლიენტის გამშვებ ანგარიშთან შესაბამისობისთვის, იმის ნაცვლად, რომ მოწყობილობა ყველა მომხმარებლისთვის გახსნათ ან კონტეინერი პრივილეგირებულ რეჟიმში გადაიყვანოთ.

ხილვადობა ნებართვის იგივე არ არის. root-ის საკუთრებაში არსებული და 600 რეჟიმის კვანძი არაპრივილეგირებულ მომხმარებლად მომუშავე სერვისისთვის ხილვადია და მაინც მისთვის გაუხსნელია. ჯერ სტუმრის ანგარიში შეამოწმეთ, შემდეგ საკუთრება ამ ანგარიშს მიანიჭეთ და რეჟიმი კლიენტის საჭიროებაზე ფართო არ დატოვოთ.

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

იცოდეთ, რას არ იძლევა ჩანაწერი

ხილვადი კვანძი მომუშავე VPN არ არის. კლიენტის პაკეტი მაინც უნდა დამონტაჟდეს, პროფილი მაინც უნდა იყოს ვალიდური და სერვისი მაინც უნდა გაეშვას. ავთენტიფიკაცია, მარშრუტები და DNS კლიენტის საქმედ რჩება და იქაური წარუმატებლობა მოწყობილობის ჩანაწერის სისრულის მტკიცებულება არ არის.

systemd-ს შეუძლია კიდევ ერთი შეზღუდვა დაამატოს. ერთეულს DeviceAllow-ით ან გამკაცრებული მოწყობილობის პოლიტიკით შეუძლია უარი თქვას კონტეინერის მმართველის მიერ მოწოდებულ კვანძზე წვდომაზე. როცა კვანძი არსებობს, მაგრამ სერვისი ნებართვის შეცდომას იუწყება, შეამოწმეთ ერთეულის მოწყობილობის პოლიტიკა და შეცვალეთ ეს პოლიტიკა კონტეინერის გაფართოების ნაცვლად.

ცხლად მიერთება არასავალდებულო და ცხადია. required=false-ის მქონე ჩანაწერს წყაროს ბილიკი სჭირდება და შეიძლება გამოჩნდეს ან გაქრეს ჰოსტის მოწყობილობის ცვლილებასთან ერთად. ასეთი სასიცოცხლო ციკლი მოდის-მიდის ტიპის აპარატურას შეეფერება; TUN მოწყობილობისთვის, რომელიც VPN-ს ჩატვირთვისას სჭირდება, არასავალდებულო ჩანაწერმა შეიძლება სერვისი მისი წინაპირობის არსებობამდე გაუშვას.

შეამოწმეთ ხილვადობა, გახსნა და ინტერფეისი ამ თანმიმდევრობით

ჯერ დაადასტურეთ კვანძი განკუთვნილ კონტეინერში. ბილიკი, ძირითადი და მცირე ნომრები და საკუთრება უნდა შეესაბამებოდეს ჰოსტის მოწყობილობას და თქვენს დამატებულ ჩანაწერს. კვანძის არქონა ნიშნავს, რომ მმართველმა ჩანაწერი არ გამოიყენა ან სხვა ინსტანსზე გამოიყენა.

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

შემდეგ დაადასტურეთ, რომ სერვისის ანგარიშს შეუძლია მისი გახსნა. ამ ანგარიშით მოკლე ტესტი საკუთრების პრობლემას სერვისის პრობლემისგან ჰყოფს. ბოლოს გაუშვით კლიენტი და დაადასტურეთ, რომ გვირაბის ინტერფეისი ჩნდება; მხოლოდ ეს მესამე ნაბიჯი ამტკიცებს მთელ გზას, რადგან პირველი ორი შეიძლება გაიაროს, სანამ კლიენტის პროფილი ან უნარი ჯერ კიდევ არასწორია.

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