ქვედა დონის კლიენტები ზედა VPN-ის უკან: მარშრუტი თუ NAT?

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

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

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

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

წყაროს შენარჩუნება მარშრუტიზაციით

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

თუ პასუხი დიახ არის, ლოკალური კონფიგურაცია მცირეა: გადაცემა ჩართული, ქვედა დიაპაზონს დამფარავი WireGuard peer-ის allowed-ips-ები და firewall-ის პოლიტიკა, რომელიც ორივე მიმართულებით გადასვლას უშვებს.

განზრახ წყაროს თარგმანი

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

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

ლოკალური მონაცემთა გზა მაინც უნდა მუშაობდეს

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

გამოსცადეთ ნამდვილი ქვედა მოწყობილობიდან და არა კარიბჭიდან. წყაროს მისამართია ამ სავარჯიშოს მთელი აზრი.

ერთი წყარო ნიშნავს ერთი სესიის იდენტობას

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

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

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

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

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