WireGuard-ის პირი მიუწვდომელია, სანამ მეორე მუშაობს: შემოწმების სია

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

ნაბიჯი 1: ჩაწერეთ გზა, რომელიც პაკეტმა უნდა გაიაროს

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

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

ნაბიჯი 2: შეადარეთ AllowedIPs ორივე მხარეს, და არა მხოლოდ ერთს

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

წაიკითხეთ ცოცხალი მდგომარეობა და არა ფაილი, რადგან გადატვირთვა შეიძლება ჩუმად ჩავარდნილიყო: sudo wg show wg0 allowed-ips. სერვერზე წარუმატებელი პირის ჩანაწერში უნდა იყოს მისი გვირაბის მისამართი, მაგალითად 10.90.0.3/32. კლიენტზე სერვერის პირის ჩანაწერში უნდა იყოს ის დანიშნულება, რომელსაც ამოწმებთ, იქნება ეს ჰაბის გვირაბის მისამართი თუ დაშორებული ქვექსელი. გადამფარავი დიაპაზონები ძიებას ორაზროვანს ხდის და შეიძლება აირჩიოს ის პირი, რომელიც არ გინდოდათ, ამიტომ გამოყავით ისინი.

ნაბიჯი 3: შეამოწმეთ შიდა წყაროს მისამართი

კლიენტი, რომელიც 10.90.0.3-ს wg0-ის გავლით მარშრუტიზაციას უკეთებს, მაგრამ პაკეტებს საკუთარი Wi-Fi მისამართიდან აგზავნის, მიმღების მიერ უარყოფილი იქნება, რადგან წყარო არ ემთხვევა პირის AllowedIPs-ს. დაადასტურეთ, რას ირჩევს რეალურად ბირთვი ip route get 10.90.0.3 from 10.90.0.2-ით, და დაადასტურეთ გვირაბის ინტერფეისზე მინიჭებული მისამართი ip -brief addr show wg0-ით.

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

ნაბიჯი 4: გადახედეთ ჰაბის გადამისამართებას და უკუგზას

თუ ჰაბმა პირებს შორის უნდა გადაამისამართოს, ბირთვს სჭირდება net.ipv4.ip_forward=1, ხოლო ფაირვოლმა უნდა მიიღოს გადამისამართებული ნაკადი: შესვლა wg0-ზე, გასვლა wg0-დან, გამომგზავნის გვირაბის მისამართიდან მიმღების მისამართამდე. ხშირი ხარვეზია შესვლის წესი, რომელიც იღებს UDP 51820-ს, მაგრამ გადამისამართების წესი არ არსებობს], ამიტომ ხელის ჩამორთმევა წარმატებით სრულდება და დატვირთვა იღუპება. ჩამოთვალეთ მოქმედი წესები sudo nft list ruleset-ით ან თქვენი ფაირვოლის მენეჯერის ეკვივალენტით.

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

ბოლოს, გამოყავით ხელის ჩამორთმევა მონაცემებისგან. პირი, რომელიც ხელის ჩამორთმევას ასრულებს, მაგრამ დიდი გადაცემებისას იჭედება, ჩვეულებრივ MTU ან MSS პრობლემა აქვს სწორედ ამ გზაზე და არა AllowedIPs პრობლემა. ჯერ პატარა ping-ით სცადეთ, შემდეგ სრული ზომის ping-ით, და შეადარეთ ორი პირი.

ნაბიჯი 5: შეცვალეთ ერთი რამ და მომუშავე პირი ხელუხლებელი დატოვეთ

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

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