OpenVPN სასტუმროს Wi-Fi-ზე არ უკავშირდება? სცადეთ TCP 443

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

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

დაიწყეთ კლიენტიდან: წაიკითხეთ მდგომარეობის ხაზი

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

შემდეგ შეამოწმეთ ქსელი უკვე ხელთ არსებული ხელსაწყოებით. nc -vzu 203.0.113.10 1194 აგზავნის UDP დეიტაგრამას, curl -v telnet://203.0.113.10:443 ახსენებს, სრულდება თუ არა TCP ხელის ჩამორთმევა, ხოლო HTTPS გვერდის ჩამტვირთავი ბრაუზერი მხოლოდ იმას ამტკიცებს, რომ გარე 443 აღწევს ამ ერთ ჰოსტამდე. პატარა შემოწმებები პასუხობს იმას, რაც VPN კლიენტს არ შეუძლია: რომელი პორტი და რომელი ოქმი საერთოდ გადის ამ ქსელიდან.

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

მსმენელი და პროფილი ერთად გადაიტანეთ

სერვერის მხარეს დააყენეთ მსმენელი იმაზე, რასაც ქსელი უშვებს: port 443 და proto tcp სერვერის კონფიგურაციაში, შემდეგ გადატვირთეთ სერვისი და დაადასტურეთ სოკეტი ss -lntp-ით. კლიენტის მხარეს პროფილი უნდა დაეთანხმოს, რადგან ტრანსპორტი და პორტი გვირაბის გარეთ არიან: proto tcp და port 443 .ovpn-ში, ან შესაბამისი ველები აპის პარამეტრების ეკრანზე. ჯერ კიდევ UDP 1194-ზე მიმართული პროფილი ზუსტად ისე ვარდება, როგორც ადრე, და ცდუნებაა დაადანაშაულოთ უკვე გასწორებული ფაილვოლი. თუ იგივე ჰოსტი 443-ზე HTTPS-საც პასუხობს, ორი მსმენელი ვერ გაიზიარებს ამ მისამართსა და ოქმს; მიეცით VPN-ს მეორე მისამართი ან წინ დადგით დემულტიპლექსერი.

თვალყური ადევნეთ პირველ კავშირს tcpdump -ni any port 443-ით ორივე ბოლოში. პაკეტები, რომლებიც კლიენტიდან გადის და არასდროს აღწევს, ნიშნავს, რომ ქსელი მაინც ფილტრავს, ან პროფილში მოცემული მისამართი არ არის ის, რასაც ვარაუდობთ. პასუხის გარეშე მისული პაკეტები გაბრუნებთ სერვერის ჟურნალთან, სადაც ოქმის შეუთანხმებლობა მაშინვე გამოჩნდება როგორც გადაგდებული პაკეტი.

როცა ქსელიდან მხოლოდ პროქსი გადის

ზოგიერთი სტუმართა ქსელი HTTP პროქსის გარდა არაფერს უშვებს, რაც დახურული პორტისგან განსხვავებული შეზღუდვაა და OpenVPN-ზე მეტს გამორიცხავს. კლიენტები, რომლებიც მხოლოდ PPTP-ს, L2TP/IPsec-ს ან შიშველ IPsec-ს საუბრობენ, გასასვლელი არ აქვთ, რადგან ეს დიზაინები მოელოდებიან, რომ მათი გარე ოქმი პირდაპირ მიაღწევს სერვერს. OpenVPN-ს შეუძლია, http-proxy proxy.example.net 8080-ით კლიენტის პროფილში, იმ პირობით, რომ პროქსი დაუშვებს CONNECT მეთოდს თქვენს პორტზე. SOCKS პროქსი კიდევ უფრო მარტივია, რადგან ნაკადს გადასცემს იმის გარეშე, რომ აინტერესებდეს, რა არის შიგნით.

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

შეაფასეთ სარეზერვო გზის ფასი, სანამ შეინარჩუნებთ

TCP-ს TCP-ის შიგნით ცნობილი ფასი აქვს. როცა გარე კავშირი TCP-ია და დატვირთვაც TCP, დაკარგული სეგმენტი ორივე ფენაზე იწვევს ხელახლა გაგზავნას და შიდა კავშირი უკან იხევს დანაკარგისგან, რომელსაც ვერ ხედავს. დათვალიერება ამას უძლებს; ინტერაქტიული სესიები და ზარები მას გრძნობენ. შეინახეთ TCP 443 მსმენელი როგორც სარეზერვო გზა იმ ქსელებისთვის, რომლებიც მას ითხოვენ, და დატოვეთ UDP ნაგულისხმევად ყველაფრისთვის, რაც ჯერ კიდევ უშვებს მას.

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