WireGuard მუშაობს მობილურ მონაცემებზე, მაგრამ არა იმავე wifi-ზე
LAN-ის შიგნიდან როუტერის საჯარო მისამართზე მიმავალი მოთხოვნა სხვა გზას გადის, ვიდრე მობილური მონაცემებიდან მომავალი. სცადეთ გარეთ და შემდეგ აირჩიეთ ლოკალური გზა.
გვირაბი მობილურ მონაცემებზე ადის და შემდეგ სახლში დაკავშირებაზე რჩება, იმავე პროფილით, იმავე peer გასაღებით და შუალედში კონფიგურაციის ცვლილების გარეშე. განსხვავება მოგზაურობაშია: LAN-ის შიგნიდან როუტერის საჯარო მისამართზე მიმავალი მოთხოვნა არ არის იგივე მოგზაურობა, რაც ინტერნეტიდან მომავალი მოთხოვნა. სახლის კარიბჭეების უმეტესობა ან საერთოდ არ ახორციელებს დაბრუნების გზას, ან მხოლოდ გარკვეული პროტოკოლებისთვის ახორციელებს. ეს სიმპტომს გატეხილი გასაღების სახეს აძლევს, თუმცა გასაღებში არაფერი შეცვლილა. დაადგინეთ, რომელი გზა ჩავარდა, სანამ გასაღებს, პორტის გადამისამართებას ან კლიენტის პროფილს შეეხებით.
ერთი მისამართი, ორი განსხვავებული გზა
გარედან პაკეტი აღწევს როუტერის საჯარო მისამართამდე და პორტის გადამისამართების წესი გადასცემს მას შიდა ჰოსტზე მდებარე WireGuard-ის მსმენელს. შიგნიდან კლიენტი იმავე საჯარო მისამართს იძახებს, ამიტომ პაკეტი ტოვებს კლიენტს, აღწევს როუტერამდე და უნდა შებრუნდეს LAN-ისკენ. სწორედ ამ შებრუნებაზე იშლება ორი გზა, რადგან როუტერმა უნდა თარგმნოს ნაკადი, რომელიც ერთდროულად გადის და ისევ შემოდის იმავე ინტერფეისში. ბევრი იმპლემენტაცია მას თარგმნის ნაცვლად ყრის, და კლიენტი შემდეგ ხელის ჩამორთმევას ელოდება, რომელიც არასდროს გაიგზავნა.
ამ ქცევას ჩვეულებრივ NAT loopback ან hairpinning ეწოდება და ის როუტერს ეკუთვნის და არა WireGuard-ს; RFC 4787 ასახავს თარგმნის იმ შემთხვევებს, როცა კარიბჭემ შეიძლება დაუჭიროს მხარი ან არ დაუჭიროს. WireGuard თავად გზაზე აზრს არ გამოთქვამს, რადგან მხოლოდ იმ პაკეტებს ხედავს, რომლებიც მის ინტერფეისამდე აღწევს. როცა როუტერი ნაკადს ყრის, დემონი არასდროს იღებს არაფერს, კლიენტი იუწყება ხელის ჩამორთმევის დროის ამოწურვას და სერვერის ჟურნალი ცარიელი რჩება. ცარიელი ჟურნალი ამიტომ მინიშნებაა, სად გაჩერდა პაკეტი, და არა მტკიცება, რომ სერვერი ჩამოვარდა. ეს არის ასევე მიზეზი, რატომ არაფერს ცვლის ხელახლა დაყენება.
საპირისპიროც მნიშვნელოვანია: სერვერის ჟურნალი, რომელიც LAN-ის მისამართიდან ხელის ჩამორთმევის მცდელობას აჩვენებს, ამტკიცებს, რომ პაკეტი მოვიდა და გზა რიგზეა, რაც გამოძიებას გასაღებებსა და ნებადართულ მისამართებზე გადააქვს. წაიკითხეთ ჟურნალი იმისთვის, რასაც ამტკიცებს და არა იმისთვის, რისი ნახვაც გინდოდათ.
ხელახლა წარმოქმნით სანამ რამეს შეცვლით
სცადეთ ნებადართული გარე ქსელიდან იმავე მოწყობილობითა და იმავე პროფილით, შემდეგ გაიმეორეთ ტესტი LAN-ის შიგნით არაფრის რედაქტირების გარეშე. გარეთ დასრულებული ხელის ჩამორთმევა და შიგნით მოწყობილობიდან არასდროს გამავალი კლიენტი მდგომარეობას გამოცნობის ნაცვლად ხელახლა წარმოქმნის. ორივე მცდელობამ იგივე პროფილი უნდა გამოიყენოს, თორემ შედარება არაფერს ამტკიცებს.
შემდეგ ნახეთ, რას იხსნის საბოლოო წერტილის სახელი ამ მოწყობილობისთვის. შემდეგი სამი ბრძანება ასევე აჩვენებს, რომელ მისამართს დაურეკა კლიენტმა სინამდვილეში:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netპირველი ბრძანება იუწყება საბოლოო წერტილს, რომელსაც ინტერფეისი ახლა იყენებს, დანარჩენი ორი კი აჩვენებს, რას იხსნის სახელი ამ მანქანაზე. კლიენტი, რომელიც საჯარო მისამართს იძახებს სერვერის იმავე ქსელში ყოფნისას, hairpin გზას იყენებს. კლიენტი, რომელიც LAN-ის მისამართს იძახებს, ამას არ აკეთებს, და იქაური ჩავარდნა სხვა გამოძიებას ეკუთვნის. ეს განსხვავება წყვეტს, საერთოდ ხომ არ ეხება შემდეგი ნაწილი.
ახლომდებარე სერვერთან მისვლის მხარდაჭერილი გზები
ყველაზე სუფთა მოწყობა ჰორიზონტის გაყოფილი პასუხია: საჯარო სახელი ინტერნეტისთვის საჯარო მისამართზე იხსნება, შიგნითა კლიენტებისთვის კი სერვერის LAN მისამართზე. პროფილი ინახავს ერთ საბოლოო წერტილის სახელს და გადამწყვეტი ირჩევს გზას. ეს შიდა DNS პასუხის კონტროლს მოითხოვს, რომელსაც სახლის როუტერი ჩვეულებრივ გვთავაზობს და ორგანიზაციას შეუძლია განზრახ მოაწყოს. ამ კონტროლის გარეშე დარჩენილი არჩევანი როუტერის ფუნქცია ან მეორე პროფილია.
როუტერის ფუნქცია არეკვლაა: კარიბჭე ნაკადს შიგნიდან გარეთ თარგმნის და ისევ შიგნით აბრუნებს. სადაც მუშაობს, კლიენტის ცვლილება არ სჭირდება, სადაც არ მუშაობს, ვერც ერთი კლიენტის პარამეტრი ვერ იხსნის. სცადეთ ის როუტერის ფუნქციების სიის წაკითხვის ნაცვლად შიდა მცდელობის დროს სერვერის ჟურნალზე დაკვირვებით.
პროფილის კერძო მისამართზე რედაქტირება დიაგნოზია და არა დიზაინი. ის ამტკიცებს, რომ სერვერი LAN-ზე პასუხობს, და იმავე პროფილს ამტვრევს იმ მომენტში, როცა ლეპტოპი სახლს ტოვებს.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
შეინარჩუნეთ პროფილი გამოსადეგი სახლიდან შორს
რომელ გზასაც არ უნდა აირჩიოთ, იდენტობის შემოწმება მშვიდად დატოვეთ. საბოლოო წერტილის მისამართი peer-ის იდენტობა არ არის და მისამართის ცვლილება არასდროს ამართლებს შემთხვევით მპასუხობს უკავშირო საჯარო გასაღების მიღებას. WireGuard გასაღებით ადასტურებს, ამიტომ არასწორი ჰოსტი ხელის ჩამორთმევაზე ვარდება და არა მოულოდნელ რამეზე წვდომას აძლევს.
თუ საჯარო მისამართი მოძრაობს, სახელს სასარგებლოდ ინახავს დინამიკური DNS და კლიენტის განახლების ქცევა წყვეტს, რამდენად სწრაფად მოვა ცვლილება. სცადეთ ეს გარედან მისამართის ცვლილების შემდეგ, რადგან LAN-ის შემთხვევა ვერ დაადასტურებს. მიაქციეთ ყურადღება გადამწყვეტს, რომელიც ძველ პასუხს ჩანაწერის სიცოცხლის ხანგრძლივობაზე მეტხანს ინახავს ქეშში. სახელი, რომელიც ჯერ კიდევ წინა მისამართზე მიუთითებს, ზუსტად ჩამოვარდნილ სერვერს ჰგავს.
ჩაწერეთ, რომელ სახელს იყენებს პროფილი და რას იხსნის ის საზღვრის თითოეულ მხარეს. პროფილი, რომელიც დამოკიდებულია როუტერის ფუნქციაზე, რომელიც არავის ჩაუწერია, არის მხარდაჭერის ზარი, რომელიც შემდეგ firmware განახლებას ელოდება. ჩანაწერი ასევე არის ის, რაც შემდეგ ადამიანს ეუბნება, შიდა ჩავარდნა ცნობილი hairpin შემთხვევაა თუ რაღაც ახალი.