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

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

საბოლოო წერტილის ცოდნა და არა ხელმისაწვდომობა

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

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

როგორ სწავლობს მხარე საბოლოო წერტილს

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

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

მდგომარეობის მქონე თარგმანი საკუთარ მიმართულებას ამატებს

სადაც UDP გადის მთარგმნელ კარიბჭეში, კარიბჭე ქმნის მდგომარეობას პირველი დანახული პაკეტისთვის. RFC 4787 აღწერს ამ ქცევას და დროის ლიმიტებს, რომლებიც საბოლოოდ აშორებს რუკებას. უმოქმედო რუკება იწურება, და შორეული მხრიდან შემოსული პაკეტი შემდეგ კარიბჭის მიერ გადაგდებულად იგდება, სანამ ჰოსტამდე მიაღწევს. მთელი დილით მომუშავე გვირაბი შუადღის შემდეგ წყვეტს პასუხს სწორედ ამ მიზეზით.

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

კონფიგურაცია გაუკეთეთ იმ მიმართულებას, რომელიც ნამდვილად გსურთ

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

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

შეადარეთ მდგომარეობა ტრიგერამდე და მის შემდეგ

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

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

ჩაწერეთ საბოლოო წერტილის სვეტი და თარგმანის ჩანაწერი ერთად. მხარე საბოლოო წერტილის გარეშე და კარიბჭე რუკების გარეშე ორი განსხვავებული გაუმართაობაა. მათგან მხოლოდ ერთს ასწორებს keepalive.