SoftEther NAT-ის უკან: პირდაპირი გავლა თუ VPN Azure-ის რელე?

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

სამი მექანიზმი, სამი განსხვავებული დაპირება

დინამიკური DNS სახელდებაა. ის ინახავს ჰოსტის სახელს მიმართულ ცვალებად მისამართზე, რათა ადამიანებმა ნომრის დევნა შეწყვიტონ, და სხვა არაფერს აკეთებს. მშობლიური NAT-ის გავლა კოორდინაციაა: ორი SoftEther ბოლო წერტილი ცვლის ინფორმაციას და ცდილობს გახსნას გამოსაყენებელი UDP გზა მათ შორის არსებული თარგმნის მოწყობილობებით. VPN Azure რელეა: სერვერი გარეთ უკავშირდება სერვისს, კლიენტები კი მოდიან რელეს ინფრასტრუქტურაზე არსებული ჰოსტის სახელით.

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

გადაწყვიტეთ კლიენტისა და ქსელის მიხედვით

არჩევანი კლიენტით იწყება, რადგან გავლა მხოლოდ SoftEther-ის მშობლიურ კავშირის მექანიზმში არსებობს. იმავე სერვერზე OpenVPN, L2TP/IPsec და SSTP მსმენელები მას არ მემკვიდრეობით იღებენ, თუმცა ჰოსტს იზიარებენ. ნახეთ, რას გაუშვებს მომხმარებელი, შემდეგ რას უშვებს ქსელი. კორპორატიული ქსელი, რომელიც მხოლოდ TCP 443-ს უშვებს, ამ პორტზე რელესკენ გიბიძგებთ, ხოლო ქსელი, რომელიც გაატარებს გავლისთვის საჭირო UDP პორტებს, შეიძლება პირდაპირი გზა სცადოს; ორივე შეამოწმეთ რეალური გასვლის პოლიტიკის წინააღმდეგ.

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

დაადასტურეთ, რომელი ტრანსპორტი აირჩია სესიამ

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

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList აჩვენებს, რომელი სესიებია დაკავშირებული, ხოლო SessionGet ერთ-ერთ მათგანზე აცნობებს კავშირის ტიპს, მათ შორის, მოვიდა თუ არა სესია რელეს მეშვეობით. ჩანაწერი, რომელიც რელეს ინფრასტრუქტურაზე წყდება, გეუბნებათ, რომ სესია მესამე მხარეში გადის, რაც შეგიძლიათ დაადასტუროთ ამ მარშრუტის ტესტში დაბლოკვით. მშობლიური კლიენტით UDP აჩქარებამ შეიძლება მონაცემთა გზა მართვის გზისგან მოშორებით გადაიტანოს, ამიტომ ერთი დაკვირვება მთელ სესიას არ აღწერს. მისამართის ცვლილების შემდეგ მოძველებული დინამიკური DNS სახელი და რელე, რომელიც პასუხობს, მაშინ როცა backend-ის გზა აკლია, ორი წარუმატებლობის რეჟიმია, რომლებიც ცალ-ცალკე ღირს შემოწმება. ჩაწერეთ ის, რაც გაზომეთ და არა ის, რაც დიზაინს ჰქონდა განზრახული.

დაგეგმეთ, რაზეა დამოკიდებული არჩეული გზა

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

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