რა Linux შესაძლებლობები სჭირდება თქვენს VPN პროცესს?
ინტერფეისის კონფიგურაცია, მარშრუტები, მოწყობილობაზე წვდომა და ჩვეულებრივი სოკეტები ცალკეული უფლებებია. დაასახელეთ წარუმატებელი ოპერაცია, სანამ CAP_NET_ADMIN-ს მისცემთ.
VPN დემონს პრივილეგირებული ქსელური ოპერაციები სჭირდება, თუმცა ჩვეულებრივი აპლიკაციები გამავალ სოკეტებს ყოველგვარი უფლების გარეშე ხსნიან. სწორედ ამ ნაპრალში იწყება შესაძლებლობების შეცდომების უმეტესობა: ვიღაც ხედავს ნებართვის შეცდომას, აძლევს მთელ კომპლექტს და სერვისი მუშაობს მიზეზებით, რომლებსაც მოგვიანებით ვერავინ ხსნის. ქვემოთ მოცემული მიმოხილვა იწყება წარუმატებელი ოპერაციიდან, აკავშირებს მას ერთ უფლებამოსილებასთან და შემდეგ ამოწმებს კონტექსტს, რომელშიც პროცესი რეალურად მუშაობს. შეუზღუდავი root-ით მუშაობა ზოგიერთი განლაგებისთვის სწორი პასუხია, მაგრამ ეს გადაწყვეტილება უნდა იყოს და არა ნაგულისხმევი მნიშვნელობა.
დაიწყეთ წარუმატებელი ოპერაციიდან
წაიკითხეთ შეცდომა, სანამ სახელმძღვანელოს წაიკითხავთ. „ოპერაცია დაუშვებელია“ ინტერფეისის შეცვლისას, მოწყობილობის კვანძის გახსნაზე უარი და დაბალ პორტზე bind-ის წარუმატებლობა სამი განსხვავებული პრობლემაა სამი განსხვავებული ნებართვით. თუ პროცესი იწყება და მარცხდება მხოლოდ პირველ მარშრუტის ცვლილებაზე, ეს ასევე ნიშნავს, რომ ინტერფეისის შექმნა უკვე წარმატებით დასრულდა, რაც პასუხს საგრძნობლად ავიწროებს.
გაიმეორეთ წარუმატებლობა სერვისის გაჩერებული მდგომარეობით, შემდეგ გაუშვით ის წინა პლანზე იმავე მომხმარებლით, თუ იმპლემენტაცია ამის საშუალებას იძლევა. თქვენს მიერ დანახული შეცდომა უკეთესია, ვიდრე გამოსაცნობი ჟურნალის სტრიქონი, და აშკარას ხდის განსხვავებას შესაძლებლობის პრობლემასა და SELinux-ის ან AppArmor-ის უარყოფას შორის.
დააკავშირეთ ყოველი ოპერაცია ერთ უფლებამოსილებასთან
ცხრილი საწყისი რუკაა და არა იმპლემენტაციის დოკუმენტაციის შემცვლელი:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
ამ ცხრილის ორი სტრიქონია ის, რასაც ადამიანები ურევენ ერთმანეთს. /dev/net/tun-ის გახსნა ფაილის ნებართვის საკითხია; ბირთვისთვის იმის კონფიგურაციის თხოვნა, რაც გახსენით, შესაძლებლობის საკითხია. CAP_NET_ADMIN-ის მიცემა არ ასწორებს მოწყობილობის კვანძს, რომელსაც თქვენი სერვისის მომხმარებელი ვერ კითხულობს, ხოლო კვანძის გასწორება მარშრუტის უფლებამოსილებას არ გაძლევთ. შეამოწმეთ ორივე, სანამ რომელიმეს შეცვლით.
ბირთვის WireGuard-სა და მომხმარებლის სივრცის გვირაბის პროგრამებსაც არ აქვთ იდენტური მოთხოვნები. ბირთვის მოდულის გზა არსებულ ინტერფეისს netlink-ის მეშვეობით აკონფიგურირებს, მაშინ როცა მომხმარებლის სივრცის იმპლემენტაციას შეიძლება მოწყობილობაც დასჭირდეს და ზოგიერთი ტრანსპორტისთვის ნედლი სოკეტებიც.
წაიკითხეთ კონტექსტი: სერვისი, კონტეინერი თუ shell
ჰოსტის ქსელის სახელთა სივრცეში არსებულ შესაძლებლობას გაცილებით დიდი გავლენა შეიძლება ჰქონდეს, ვიდრე იმავე ოპერაციას განზრახ იზოლირებულ სტეკში. კონტეინერის გაშვების გარემო ჩვეულებრივ შემცირებული საზღვრების კომპლექტით იწყება; NET_ADMIN-ის დამატება კონტეინერზე, რომელიც ჰოსტის ქსელს იზიარებს, გაცილებით დიდი ნებართვაა, ვიდრე მისი დამატება კონტეინერზე საკუთარი ქსელის სახელთა სივრცით და ჰოსტის mount-ების გარეშე.
systemd ერთეულებისთვის წაიკითხეთ, რა მოქმედებს რეალურად და არა რასაც ერთეულის ფაილი თითქოს ამბობს: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities იუწყება ეფექტურ მნიშვნელობებზე, რომლებიც შეიძლება დაყენებული იყოს თქვენ მიერ დავიწყებული drop-in-ით. მოითხოვეთ ეფექტური მნიშვნელობა და არასოდეს განზრახული. Ambient შესაძლებლობები მნიშვნელოვანია, რადგან root-ის გარდა მოქმედი სერვისი მათ გარეშე კარგავს შესაძლებლობებს exec-ის განმავლობაში.
საფუძვლად აიღეთ პაკეტის ან გამოსახულების მხარდაჭერილი კონფიგურაცია. ნუ დაამატებთ ნედლი სოკეტის ნებართვებს ან პრივილეგირებულ რეჟიმს მხოლოდ იმიტომ, რომ სხვა სახელმძღვანელომ ისინი სხვა ხელსაწყოსთვის ჩამოთვალა; ეს მსჯელობა არაფერს გადასცემს და გაკარგვინებთ იზოლაციას, რომელიც გადაიხადეთ. ეჭვის შემთხვევაში არაფერი მისცეთ და წაიკითხეთ იმპლემენტაციის შენიშვნები ზუსტად იმ ოპერაციისთვის, რომელიც გჭირდებათ.
დააკვირდით, რა ხდება პრივილეგიების ვარდნის შემდეგ
ბევრი დემონი იწყება პრივილეგირებულად, აკონფიგურირებს ინტერფეისს, შემდეგ გადადის არაპრივილეგირებულ მომხმარებელზე და ინარჩუნებს გვირაბს. ამ მომენტიდან პროცესს აღარ შეუძლია მარშრუტის დამატება, firewall-ის წესის გადაწერა ან ახალი პრივილეგირებული მოწყობილობის გახსნა, რაც ნორმალურია მანამ, სანამ ხელახალ დაკავშირებას ზუსტად ეს არ დასჭირდება. მოგვიანებით ფაილების კითხვა და hook-ების შესრულება შეიძლება იმავე მიზეზით ჩავარდეს.
გამოსცადეთ მთელი სასიცოცხლო ციკლი და არა პირველი წამი: გაშვება, განახლება ან ხელახალი დაკავშირება და გაწმენდა გაჩერებისას. ინტერფეისის პირველი წარმატებული შექმნა არ ამტკიცებს, რომ ყოველი შემდგომი პრივილეგირებული ოპერაცია კვლავ იმუშავებს, და წარუმატებლობა ჩვეულებრივ საათების შემდეგ ვლინდება წარმოებაში.
იმპლემენტაციები, რომლებიც გვირაბს ღიად ინახავენ მომხმარებლის შეცვლის განმავლობაში, ჩვეულებრივ ამას აკავშირებენ გვირაბისა და გასაღებების შენარჩუნების ოფციებთან. systemd-ის მხარეს ეკვივალენტური კითხვაა, გადაურჩება თუ არა ერთეულის შესაძლებლობების ნაკრები თქვენ მიერ კონფიგურირებულ მომხმარებლის შეცვლას.
ჩაწერეთ ნებართვა და მისი მიზეზი
ჩაწერეთ ზუსტი ნებართვა, ოპერაცია, რომელსაც ის შესაძლებელს ხდის, და შეცდომა, რომელიც მან გამოასწორა. განლაგების შენიშვნებში ერთი სტრიქონი — „CAP_NET_ADMIN ერთეულის ქსელის სახელთა სივრცეში, საჭიროა ხელახალი დაკავშირების შემდეგ მარშრუტების ცვლილებისთვის“ — საკმარისია, რომ შემდეგმა ადამიანმა ნებართვა კვლავ არ გააფართოოს.
შემდეგ ყოველი განახლების შემდეგ ხელახლა წაიკითხეთ ეფექტური ნაკრები. მომწოდებლები ფუნქციებს ამატებენ, გამოსახულებები ნაგულისხმევ მნიშვნელობებს ცვლიან და შარშან არასაჭირო შესაძლებლობა შეიძლება მზიდავი გახდეს ისე, რომ ვერავინ შეამჩნიოს.