რატომ მუშაობს OpenVPN-ის პროფილი სახლში, მაგრამ სასტუმროში იშლება

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

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

ოთხი ქსელური ფაქტი იცვლება ადგილების მიხედვით

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

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

მესამე ტრანსპორტის ფილტრაციაა. ქსელები, რომლებსაც მხოლოდ დათვალიერების ნებართვა სურთ, TCP 443-ს თვითნებურ დანიშნულებამდე ატარებენ და თითქმის ყველაფერს სხვას ყრიან, UDP-ის ჩათვლით.

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

სახელების გარჩევა და შესვლის პორტალი

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

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

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

ტრანსპორტის ფილტრაცია: ჯერ UDP, TCP 443 როგორც სარეზერვო

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

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

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

მისამართების შეჯახება და IPv4-ის გარეშე აღმავალი არხები

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

მუდმივი გამოსავალია შორეული LAN-ის იშვიათ კერძო დიაპაზონში გადატანა. ისეთი დიაპაზონის არჩევა, რომელსაც სახლში არავინ იყენებს, მაგალითად 10.42.0.0/24, პრობლემას ერთის ნაცვლად ყველა მომავალი ადგილისთვის კრავს. ლოკალური შემოვლითი გზაა იმ სასტუმროს, ჰოთსპოტის ან როუტერის თავიდან აცილება, რაც საერთოდ არ არის გამოსავალი.

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

სიმპტომები გვირაბის აწევის შემდეგ

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

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