WireGuard ქსელის სახელთა სივრცში: რატომ ჩამორჩა სოკეტი

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

სიმპტომი: სწორი სახელთა სივრცე, მაგრამ პაკეტები არ არის

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

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

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

რატომ აქვს სოკეტს დაბადების ადგილი

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

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

შექმენით ის იქ, სადაც სოკეტი გსურთ

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

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

წაითხეთ გზის ორივე მხარეს

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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