Windows-ზე WireGuard სერვერის საჯარო IP-ზე SSH ვერ მუშაობს

გვირაბები, რომლებიც ადის მაშინ, როცა სერვერის საჯარო მისამართზე SSH წყვეტს მუშაობას, სერვერის მიერ კავშირის უარყოფას ჰგავს. Windows-ზე უფრო სავარაუდო მიზეზი ლოკალურია: სრული გვირაბის /0 AllowedIPs რთავს შემზღუდავ firewall-ის წესებს, რომლებიც ნებას აძლევს გვირაბის საკუთარ ტრანსპორტს და ძალიან ცოტას სხვას. დაშიფრული პაკეტები, რომლებიც ამ მისამართამდე აღწევს, არაფერს ამბობს იმაზე, შეიძლება თუ არა იმავე მისამართზე ცალკე TCP კავშირის გასვლა.

გამოჰყავით endpoint-ის საჯარო მისამართი მისი შიდა გვირაბის მისამართისგან, სანამ peer-ების სიას შეეხებით. ამის AllowedIPs-ის რედაქტირებით გასწორების თითქმის ყველა მცდელობა პოლიტიკას ასუსტებს და არა მარშრუტს ასწორებს.

მარშრუტიზაციის ნებართვა და firewall-ის ნებართვა სხვადასხვაა

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

ამიტომ endpoint-ამდე traceroute შეიძლება წარმატებული იყოს, მაშინ როცა SSH მცდელობა ვერ ახერხებს. პირველს გამონაკლისის მფლობელი სერვისი გადააქვს, მეორეს — არა.

რას აკეთებს /0 Windows-ზე

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

ეს წესები kill switch გამოთქმის უკან მდგარი მექანიზმია. ისინი კონფიგურაციის ფორმით აქტიურდება და არა ამ სახელის მქონე მოსამართებით.

გამონაკლისები იცვლის დაცვის მოდელს

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

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

გამოსცადეთ თქვენ მიერ არჩეული მართვის გზა

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

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

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