რატომ ბლოკავს ტყვე პორტალი თქვენს VPN-ს და როგორ შეხვიდეთ ისევ
საჯარო Wi-Fi ავტორიზებს თქვენს მოწყობილობას, სანამ მისგან ერთი პაკეტიც გავა. რას აგდებს პორტალი, რატომ იტყობინება თქვენი VPN ამას არასწორად და რომელი რიგით გაერთიანებთ ისევ.
ღია ქსელში თქვენი წვდომის წერტილი პაკეტებს ინტერნეტს უბრალოდ არ გადასცემს. ზემოთ მდებარე პოლიტიკის წერტილი ამოწმებს, არის თუ არა თქვენი მოწყობილობა უკვე ავტორიზებული, და სანამ არ იქნება, თითქმის ყველაფერი იგდება. თქვენი VPN კლიენტი ამ სიჩუმეს მკვდარ სერვერად კითხულობს. იგი იშვიათად ამბობს ამას: WireGuard ხელის ჩამორთმევას სიცარიელეში იმეორებს, OpenVPN კავშირის დროის ამოწურვას იტყობინება, ხოლო IKEv2 ბრუნდება 809 შეცდომით პასუხგაუცემელი დისტანციური სერვერის შესახებ.
რას აკონტროლებს პორტალი სინამდვილეში
ტყვე პორტალი ორი ერთმანეთზე მიჭედებული რამ არის: პოლიტიკის გადაწყვეტილების წერტილი და გადამისამართებელი. როცა თქვენი მოწყობილობა უერთდება და DHCP იჯარას იღებს, ქსელი თქვენ ავტორიზაციამდე მდგომარეობაში გაყენებთ.
ეს მდგომარეობა ბრენდმაუერის წესების ერთობლიობაა. ის ჩვეულებრივ უშვებს DNS-ს და უშვებს HTTP ან HTTPS-ს პორტალის ჰოსტების მოკლე სიაზე, დანარჩენს კი აგდებს. დაშვებული სია გალავნიანი ბაღია და ის თითქმის არასდროს მოიცავს VPN-ის ბოლო წერტილს.
ამ აგდებიდან არცერთი თავაზიანი არ არის. VPN სერვერისკენ მიმართული პაკეტები უარყოფის ნაცვლად იგდება, ამიტომ კლიენტი ვერ იღებს არც ICMP unreachable-ს და არც TCP reset-ს, მხოლოდ პასუხის არარსებობას. მწარმოებლის მიხედვით, გადამისამართებელმა შეიძლება 80 პორტზე უპასუხოს შესვლის გვერდზე გადამისამართებით, მაშინ როცა 443 პორტი იგდება ან იტაცება. გადამისამართებების შემჩნევა ადვილია, რადგან ისინი ჩვეულებრივ HTTP პასუხს ატარებენ; 443-ზე ჩარევას სჭირდება სერტიფიკატი, რომლის ნდობაზეც თქვენი ბრაუზერი უარს იტყვის.
თავად ავტორიზაცია ჩვეულებრივ მოწყობილობის MAC მისამართზეა მიბმული, ზოგჯერ იჯარით აღებულ IP-ზე, და ის ცხოვრობს ტაიმერიან სესიათა ცხრილში. შესვლა ქმნის ჩანაწერს. ბრენდმაუერის წესი, რომელიც თქვენს ტრაფიკს ატარებს, მხოლოდ მაშინ არსებობს, სანამ ეს ჩანაწერი არსებობს, და სწორედ ამიტომ ბრუნდება მთელი პრობლემა მოგვიანებით, თქვენ მხარეს არაფრის შეცვლის გარეშე.
რატომ კვდება VPN-ის ხელის ჩამორთმევა სანამ დაიწყება
თითოეულ პროტოკოლს თავისი ტრანსპორტი აქვს და ავტორიზაციამდელი ბრენდმაუერი თითოეულს სხვანაირად ამტვრევს. IKEv2 Windows-სა და iOS-ზე UDP 500-სა და UDP 4500-ზე მიდის; ამ პორტებზე აგდება 809-ად ვლინდება, ან სახელის გარჩევის ტიპის წარუმატებლობად იმ კლიენტებზე, რომლებიც ეტაპებს ცალ-ცალკე იტყობინებიან. OpenVPN UDP 1194-ზე რჩება დაკავშირების მდგომარეობაში, სანამ მისი დრო ამოიწურება. OpenVPN TCP 443-ზე საინტერესო შემთხვევაა, რადგან პორტალმა შეიძლება დაასრულოს TCP ხელის ჩამორთმევა და შემდეგ თავისი გადამისამართების გვერდით უპასუხოს, ამიტომ დროის ამოწურვის ნაცვლად TLS შეცდომას ხედავთ.
WireGuard მექანიზმს ყველაზე ნათლად აჩვენებს. ის დიზაინით მხოლოდ UDP-ია, TCP სარეზერვო ვარიანტის გარეშე, ამიტომ უცნობ UDP-ს აგდებული ბრენდმაუერი ტრანსპორტს სრულად აშორებს. კლიენტი აგრძელებს ხელის ჩამორთმევის დაწყებების გაგზავნას მზარდი შუალედით და იტყობინება ხელის ჩამორთმევაზე, რომელიც არასდროს სრულდება. ამ შეტყობინებაში არსად არის ნახსენები Wi-Fi და მასში არაფერი მიუთითებს, რომ ბრაუზერი უნდა გახსნათ.
პლატფორმები ცდილობენ მდგომარეობის შემჩნევას თქვენს VPN-ზე ადრე. Windows იღებს ცნობილ URL-ს, რომ გადაწყვიტოს შესვლის შეტყობინების ჩვენება, Android ითხოვს ბოლო წერტილს, რომელმაც 204 No Content უნდა უპასუხოს, ხოლო Apple-ის მოწყობილობები ხსნიან პატარა ტყვე ქსელის ფანჯარას. ეს შემოწმებები მუშაობს, რადგან პორტალი მოსალოდნელი სხეულის ნაცვლად გადამისამართებით პასუხობს. იგივე ქცევა ხსნის, როგორ შეიძლება პორტალი სრულიად ჯანმრთელად გამოიყურებოდეს, სანამ თქვენი გვირაბი მკვდარია: შემოწმება და გვირაბი სხვადასხვა წესებით ფასდება.
რას აბრუნებს სინამდვილეში სესიის ვადის გასვლა
დაწესებულებები სესიებს ამთავრებენ თქვენს VPN ანგარიშთან დაუკავშირებელი მიზეზებით: უმოქმედობის ვადა, სესიის მაქსიმალური ხანგრძლივობა, ახალი DHCP იჯარა ან სხვა წვდომის წერტილზე ხელახალი მიერთება. როცა ტაიმერი ამოქმედდება, სესიათა ცხრილის ჩანაწერი ქრება და ავტორიზაციამდელი წესების ნაკრები ბრუნდება ზუსტად ისე, როგორც რეგისტრაციისას იყო.
დამყარებული გვირაბი ხშირად საკმარისად დიდხანს ცოცხლობს, რომ ჯანმრთელად გამოიყურებოდეს. სიცოცხლის შენარჩუნების შეტყობინებები განაგრძობს გასვლას და ამის შემჩნევა კლიენტზეა დამოკიდებული, თუ როგორ ექცევა უპასუხო ტრაფიკს, ამიტომ სტატუსის შუქი შეიძლება კიდევ ცოტა ხანს მწვანე დარჩეს მას შემდეგ, რაც გზა გაქრა. შემდეგ გვირაბი ვარდება და ხელახალი დაკავშირების ყოველი ცდა იმავე დაბლოკილ პორტებზე იშლება.
ამ მომენტში კლიენტის შეცდომა გეუბნებათ, რომელ ეტაპზე ხართ, თუ ყურადღებით წაიკითხავთ:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
ერთი დეტალი ატყუებს ხალხს: როცა სესია MAC მისამართზეა მიბმული, შესვლის გვერდის ხელახლა ჩატვირთვა შეიძლება არ დაგვეხმაროს. თქვენ უნდა გაწყვიტოთ მიერთება და ისევ დაუკავშირდეთ, რომ პორტალმა ამოწურული ცდის ნაცვლად ახალი ავტორიზაციის ცდა დაინახოს.
ჯერ შედით, შემდეგ გვირაბი ასწიეთ
მოქმედი რიგი ასეთია: ავტორიზება მოწყობილობას, დაამტკიცეთ გზა, გაუშვით VPN, დაამტკიცეთ გვირაბი და შემდეგ აღადგინეთ თქვენი ჩვეული ბლოკირება. ბოლო ნაბიჯი მნიშვნელოვანია, რადგან პორტალამდე მისასვლელად საჭირო დროებითი მდგომარეობა სწორედ ის მდგომარეობაა, რომლის თავიდან ასაცილებლადაც ავარიული გამომრთველი არსებობს.
სამუშაო მაგიდის კლიენტი გვირაბის გარეთ ბლოკირების ოფციით უნდა შეჩერდეს, რომ პორტალის გვერდი ჩაიტვირთოს, და მგრძნობიარე აპლიკაციები დახურული უნდა შეინახოთ ამ გვირაბის გარეთ ფანჯრის განმავლობაში; ეს ერთადერთი ინტერვალია, როცა ლოკალური ტრაფიკი დაცვის გარეშე გადის. მართული, ყოველთვის ჩართული მოწყობილობა უნდა იყენებდეს მისი მფლობელის მიერ გამოქვეყნებულ პროცედურას და არა თქვენ მიერ პოლიტიკის მოხსნას. თუ პორტალი სერტიფიკატის გაფრთხილებას აჩვენებს, გაჩერდით: მისი მიღება თქვენს სესიას დაწესებულების ჩარევის პროქსის გავლით წარმართავს და ის პროქსი ყველაფერს წაიკითხავს, რასაც აგზავნით. Android-ზე ყოველთვის ჩართული VPN-ის ქვეშ მყოფი ჩაკეტვა ტრაფიკს გვირაბის აწევამდე ბლოკავს და ზოგიერთ ნაგებობას არ შეუძლია პორტალის ნაკადის გამოკლება; თუ თქვენსას არ შეუძლია, ჩაკეტვის გამორთული დატოვების ნაცვლად გამოიყენეთ დაწესებულების ალტერნატიული წვდომა ან სხვა მოწყობილობა. Apple-ის მოთხოვნით წესები შეიძლება დაიწეროს ისე, რომ გვირაბს უარი თქვას მანამ, სანამ შემოწმება წარმატებით დასრულდება, და ეს არის ქცევა, რომელიც სასტუმრო ქსელებზე გსურთ.
გადაამოწმეთ რიგით თქვენს ხელთ არსებული ხელსაწყოებით. გვირაბამდე გაუშვით შემოწმება ისე, რომ სათაურებიც და სხეულიც ხილული იყოს, და დააკვირდით, იღებს თუ არა თქვენი VPN ტრანსპორტი რაიმე პასუხს:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'ავტორიზაციამდე ჩვეულებრივი პორტალი ორი პასუხიდან ერთს იძლევა: 302, რომლის Location შესვლის გვერდზე მიუთითებს, ან 200 HTML სხეულით, რომელიც პორტალის გვერდია. ჩაიწერეთ, რომელი მიიღეთ. გადამისამართება შესვლამდე წარუმატებლობა არ არის; პორტალი გეუბნებათ, სად უნდა წახვიდეთ. მას შემდეგ, რაც პორტალი წარმატებას იტყობინება, გაიმეორეთ ბრძანება და დაელოდეთ 200-ს, რომლის სხეულიც სიტყვასიტყვით Success სიტყვაა. სწორედ ეს სტრიქონი ხდის შემოწმებას მნიშვნელოვანს. თუ ჰოსტი ჩვეულებრივად პასუხობს მანამ, სანამ ოდესმე შეხვალთ, ამ ქსელში ჩამჭერი პორტალი არ არის. ჩანაწერში ავტორიზაციამდელი აგდება გამავალი პაკეტებია, საიდანაც არაფერი ბრუნდება, მაშინ როცა მომუშავე გზა იმავე ნაკადზე პასუხს დაახლოებით ერთ წამში აჩვენებს. დაუკავშირდით და შემდეგ გაიმეორეთ ჩანაწერი.
თუ გვირაბი მაინც იშლება მას შემდეგ, რაც პორტალი დიახ-ს ამბობს
შესვლის წარმატება იგივე არ არის, რაც დაშვებული ტრანსპორტი. ბევრი დაწესებულება უშვებს პორტალსა და ჩვეულებრივ დათვალიერებას, სრულად ბლოკავს რა UDP-ს, რაც WireGuard-სა და UDP OpenVPN-ს გატეხილს ტოვებს, ხოლო TCP 443 მუშაობს. თუ TCP 443 გადის, UDP კი არა, ეს დაწესებულების პოლიტიკაა და არა თქვენ მიერ არასწორად გამართული კლიენტი, ამიტომ შეცვალეთ ტრანსპორტი ან მიიღეთ შეზღუდვა და გააგრძელეთ. თუ ხელახალი დაკავშირება ამის შემდეგაც იშლება, შეინახეთ ზუსტი შეცდომა; ის ასახელებს ეტაპს, სადაც გაჭედილი ხართ.
სხვა წარუმატებლობები მოწყობილობაში ცხოვრობს. ძველ MAC-ზე ჯერ კიდევ მიბმული სესია, საკუთარი იჯარით მეორე Wi-Fi ადაპტერი, ან კლიენტი, რომელმაც პორტალის სერტიფიკატის გამონაკლისი დააქეშა, თითოეულ მათგანს შეუძლია განაგრძოს იშლება სუფთა ხელახალი ავტორიზაციის შემდეგ. გაწყვიტეთ მიერთება, ხელახლა ავტორიზეთ და ერთხელ სცადეთ, სანამ კლიენტის პარამეტრებს შეეხებით. თუ გსურთ თქვენ მიერ დაკვირვებული კომპონენტების მიღმა არსებული არქიტექტურა, RFC 8952 ღირს წაკითხვად.
თუ თავად პორტალი უარს ამბობს ავტორიზაციაზე, პრობლემა ანგარიშში ან მოწყობილობის განაწილებაშია და ვერც ერთი VPN პარამეტრი ვერ გამოასწორებს მას. VPN-ის გამოსვლის ქვეყნის შეცვლა არ აბრუნებს დაწესებულების ლოკალურ წვდომის მდგომარეობას; ეს ცხრილი თქვენს მოწყობილობაზეა მიბმული და არა არჩეულ სერვერზე. ჰკითხეთ დაწესებულების ოპერატორს და მიეცით დრო, რადგან ის სესიათა ცხრილს შეხედავს.
შემდეგ მოგზაურობამდე ჩაწერეთ სამი რამ: პორტალის გვერდი, როგორც ნულოვანი ნაბიჯი, ბლოკირების შეჩერების ნაბიჯი თითოეული მოწყობილობისთვის, რომელსაც თან ატარებთ, და ერთი სარეზერვო ტრანსპორტი, რომელიც ნამდვილად გამოსცადეთ. როცა ათი წუთის წინ მომუშავე გვირაბი ისევ გაჩერდება, მოექეცით მას როგორც ამოწურულ ავტორიზაციას და ხელახლა შეამოწმეთ პორტალი, სანამ VPN პროფილს შეეხებით.