ჩვეულებრივი Linux აპი VPN-ს იყენებს TUN-ზე შეხების გარეშე

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

თვალი ადევნე ერთ პაკეტს სოკეტიდან გვირაბამდე

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

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

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

გადაწყვიტე, ვის სჭირდება მოწყობილობა და ვის არა

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

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

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

შეამოწმე, რომელ სახელთა სივრცეში მუშაობს აპი სინამდვილეში

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

შეამოწმე ip netns list და ip -n NAME route-ით, ან პროცესის სახელთა სივრცის ბმულის დათვალიერებით. პასუხი ჩვეულებრივ ერთ ბრძანებაში ჩანს.

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

გამოყავი შესაძლებლობები ქსელური პოლიტიკისგან

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

პროგრამა, რომელიც საკუთარ გვირაბს ახორციელებს, მესამე შემთხვევაა. ის ნამდვილად ხსნის TUN-ს, რადგან დემონის როლს იღებს, ამიტომ სჭირდება დემონის პრივილეგიები.

დაასახელე ოპერაცია სანამ პრივილეგიას დაასახელებ. ეს ორი ჩვეულებრივ უფრო ადვილად გაიყოფა, ვიდრე ჩანს.

გადაამოწმე გაყოფა ორი ანგარიშით

დაუკავშირე გვირაბი როგორც სერვისი, შემდეგ გაუშვი აპი ჩვეულებრივი მომხმარებლის როლში და დაადასტურე, რომ ის აღწევს კერძო რესურსამდე. შეამოწმე ip route get დანიშნულებისთვის ამ მომხმარებლის shell-იდან, რომ ნახო, რომელი ინტერფეისი აირჩა. თუ მარშრუტი სწორია და კავშირი მაინც ვერ მყარდება, პრობლემა პოლიტიკაა და არა პრივილეგია.

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