ერთი Linux ანგარიშის OpenVPN-ით მარშრუტიზაცია UID წესით

ანგარიშზე დაფუძნებული მარშრუტიზაცია შესაფერისია, როცა ერთი Linux მომხმარებლის საკუთრებაში არსებული ყოველი IPv4 სოკეტი არსებული გვირაბიდან უნდა გავიდეს, და არ არის შესაფერისი, როცა პროგრამის დონეზე იზოლაცია გჭირდებათ. ის UID-ის მიხედვით ირჩევს, ამიტომ ამ ანგარიშით მოქმედი ყველაფერი ფარგლებშია, მათ შორის დავიწყებული პაკეტური დავალება. გადაწყვიტეთ ეს საკითხი, სანამ ერთ ip rule-ს შეეხებით.

ქვემოთ მოცემული მაგალითი ვარაუდობს UID 1500-ზე გამოყოფილ ბრაუზერის ანგარიშს, 10.80.0.11 ლოკალურ მისამართის მქონე გვირაბის მოწყობილობას tun-office და VPN-ს, რომელიც ნებადართულია განსახილველი დანიშნულებებისთვის. თვით დემონი ამ UID-ის გარეთ მუშაობს.

სამი პირობა, რომლებიც მექანიზმს ირჩევს

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

თავიდან ასაცილებელი შეცდომაა ვიფიქროთ, რომ გამშვები განსაზღვრავს მფლობელს. ბრაუზერს, რომელსაც სხვა მომხმარებლის სესიამ URL გადასცა, UID 1500-ის ქვეშ სოკეტები არ შეუქმნია და არც ერთი წესი არ გადაიტანს მის მიერ გენერირებულ ტრაფიკს.

ცხრილი, წესი და მცველი

არსებული წესების შემოწმებისა და გამოუყენებელი ცხრილისა და პრიორიტეტის ნომრების არჩევის შემდეგ განლაგება მოკლეა: ნაგულისხმევი მარშრუტი გამოყოფილ ცხრილში, რომელიც გვირაბის წყაროს მისამართს ატარებს, წესი, რომელიც ანგარიშის ძიებებს ამ ცხრილში აგზავნის, და დამამთავრებელი წესი, რომელიც სარეზერვო გზას ბლოკავს. წერილობით ეს არის idempotent მარშრუტის ჩანაცვლება, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, რასაც მოჰყვება ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

მცველი არის ip -4 rule add priority 12101 uidrange 1500-1500 unreachable და ის უფრო მნიშვნელოვანია, ვიდრე მისი სიგრძე გვაფიქრებინებს. მის გარეშე 51820 ცხრილში დაკარგული მარშრუტი ჩვეულებრივ ზედა არხზე ვარდება და ანგარიში ჩუმად ჟონავს იმ ტრაფიკს, რომელიც პოლიტიკას უნდა დაეჭირა. მასთან ერთად იგივე ხარვეზი ხდება ვადის გასვლა, ანუ ბლოკირება და არა სარეზერვო გზა.

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

რას გამოტოვებს UID მარშრუტიზაცია: DNS

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

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

IPv6-ს დიზაინში საკუთარი წინადადება სჭირდება

ზემოთ მოცემული წესები მხოლოდ IPv4-ს ფარავს. თუ მოთხოვნაა IPv4 გვირაბი ამ ანგარიშიდან პირდაპირი IPv6-ის გარეშე, დაამატეთ გადამოწმებული დამამთავრებელი წესი, მაგალითად ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, შემდეგ შეამოწმეთ ადრინდელი IPv6 წესები და loopback გამონაკლისები, რომელთა შენახვაც გსურთ.

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

შეამოწმეთ ნამდვილი ანგარიშით, შემდეგ აიღეთ სასიცოცხლო ციკლი

შეადარეთ ძიებები: ip -4 route get 198.51.100.25 uid 1500 იმავე დანიშნულების მიმართ ჩვეულებრივი UID-ით. შემდეგ გააკეთეთ ნებადართული მოთხოვნა გამოყოფილი ანგარიშის ქვეშ და შეამოწმეთ წყაროს მისამართი, რომელსაც შორეული მხარე ხედავს. სასურველი წყაროს მისამართი source NAT არ არის და ის არ გადაფარავს აპლიკაციას, რომელიც სხვას აკავშირებს. თუ ორივე ძიება ერთსა და იმავე გზას აბრუნებს, წესი იმას არ აკეთებს, რასაც ფიქრობთ.

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