Niyə tutma portalı VPN-inizi bağlayır və necə yenidən daxil olmaq lazımdır

Açıq şəbəkədə giriş nöqtəniz paketləri sadəcə internetə ötürmür. Yuxarı axındakı siyasət nöqtəsi cihazınıza hələ icazə verilib-verilmədiyini yoxlayır və icazə verilməyənə qədər demək olar ki, hər şey atılır. VPN müştəriniz bu səssizliyi ölü server kimi oxuyur. Bu barədə nadir hallarda danışır: WireGuard əl sıxışmasını boşluğa təkrar göndərir, OpenVPN bağlantı vaxtının bitdiyini bildirir və IKEv2 cavab verməyən uzaq server barədə 809 xətası ilə qayıdır.

Portal əslində nəyə nəzarət edir

Tutma portalı bir-birinə bərkidilmiş iki şeydir: siyasət qərar nöqtəsi və yönləndirici. Cihazınız qoşulub DHCP icarəsi aldıqda şəbəkə sizi icazədən əvvəlki vəziyyətə salır.

Bu vəziyyət firewall qaydalar toplusudur. Adətən DNS-ə və qısa bir portal hostları siyahısına HTTP və ya HTTPS-ə icazə verir, qalan hər şeyi atır. İcazə verilən siyahı divarla əhatə olunmuş bağdır və demək olar ki, heç vaxt VPN son nöqtəsini əhatə etmir.

Atmaların heç biri nəzakətli deyil. VPN serverinə yönəlmiş paketlər rədd edilmək əvəzinə atılır, buna görə müştəri nə ICMP unreachable, nə də TCP reset alır, yalnız cavabın olmamasını alır. Vendordan asılı olaraq yönləndirici 80 portuna giriş səhifəsinə yönləndirmə ilə cavab verə bilər, halbuki 443 portu atılır və ya kəsilir. Yönləndirmələri asanlıqla görmək olar, çünki onlar adi HTTP cavabı daşıyır; 443-də kəsmə isə brauzerinizin etibar etməyəcəyi sertifikat tələb edir.

İcazənin özü adətən cihazın MAC ünvanına, bəzən icarəyə götürülmüş IP-yə bağlanır və taymerli sessiya cədvəlində yaşayır. Daxil olmaq bir giriş yaradır. Trafikinizi keçirən firewall qaydası yalnız həmin giriş mövcud olduqca mövcuddur, buna görə də sizin tərəfinizdə heç nə dəyişmədən bütün problem sonra qayıdır.

Niyə VPN əl sıxışması başlamadan ölür

Hər protokolun öz nəqliyyatı var və icazədən əvvəlki firewall hər birini fərqli şəkildə pozur. Windows və iOS-da IKEv2 UDP 500 və UDP 4500 üzərində işləyir; bu portlarda atılma 809 kimi və ya mərhələləri ayrıca bildirən müştərilərdə ad həlli tipli uğursuzluq kimi üzə çıxır. UDP 1194 üzərində OpenVPN vaxtı bitənə qədər qoşulma vəziyyətində qalır. TCP 443 üzərində OpenVPN maraqlı haldır, çünki portal TCP əl sıxışmasını tamamlaya və sonra yönləndirmə səhifəsi ilə cavab verə bilər, buna görə vaxt bitməsi əvəzinə TLS xətası görürsünüz.

WireGuard mexanizmi ən aydın göstərir. Dizaynına görə yalnız UDP-dir, TCP ehtiyat variantı yoxdur, buna görə naməlum UDP-ni atan firewall nəqliyyatı tamamilə aradan qaldırır. Müştəri artan fasilələrlə əl sıxışması başlatmaları göndərməyə davam edir və heç vaxt tamamlanmayan əl sıxışması bildirir. O mesajda heç nə Wi-Fi-dan danışmır və heç nə brauzer açmağı təklif etmir.

Platformalar vəziyyəti VPN-dən əvvəl görməyə çalışır. Windows giriş bildirişini göstərib-göstərməyəcəyinə qərar vermək üçün məlum URL götürür, Android 204 No Content cavabı verməli olan son nöqtəyə sorğu göndərir və Apple cihazları kiçik tutma şəbəkəsi pəncərəsi açır. Bu yoxlamalar işləyir, çünki portal gözlənilən gövdə əvəzinə yönləndirmə ilə cavab verir. Eyni davranış portalın tamamilə sağlam görünə bilməsini izah edir, halbuki tuneliniz ölüdür: yoxlama və tunel fərqli qaydalarla qiymətləndirilir.

Sessiyanın bitməsi əslində nəyi sıfırlayır

Məkanlar sessiyaları VPN hesabınızla əlaqəsi olmayan səbəblərdən bitirir: boş qalma vaxtı, maksimum sessiya uzunluğu, yeni DHCP icarəsi və ya fərqli giriş nöqtəsinə yenidən qoşulma. Taymer işə düşdükdə sessiya cədvəlindəki giriş yox olur və icazədən əvvəlki qaydalar toplusu qeydiyyat zamanı olduğu kimi qayıdır.

Qurulmuş tunel çox vaxt sağlam görünəcək qədər uzun yaşayır. Canlılıq mesajları göndərilməyə davam edir və müştərinin bunu görüb-görməməsi cavabsız trafiklə necə davrandığından asılıdır, buna görə yol getdikdən sonra da status işığı bir müddət yaşıl qala bilər. Sonra tunel düşür və hər yenidən qoşulma cəhdi eyni bloklanmış portlarda uğursuz olur.

O anda müştəri xətası hansı mərhələdə olduğunuzu deyir, əgər diqqətlə oxusanız:

Bir detal insanları çaşdırır: sessiya MAC ünvanına bağlı olduqda giriş səhifəsini yeniləmək kömək etməyə bilər. Əlaqəni kəsib yenidən qoşulmalısınız ki, portal bitmiş cəhd əvəzinə yeni icazə cəhdi görsün.

Əvvəlcə daxil olun, sonra tuneli qaldırın

İşləyən ardıcıllıq budur: cihaza icazə verin, yolu sübut edin, VPN-i başladın, tuneli sübut edin, sonra normal bloklamanızı bərpa edin. Bu son addım vacibdir, çünki portala çatmaq üçün lazım olan müvəqqəti vəziyyət məhz kill switch-in qarşısını almaq üçün mövcud olduğu vəziyyətdir.

Tuneldən kənarı bloklama seçimi olan masaüstü müştərisi portal səhifəsinin yüklənməsi üçün müvəqqəti dayandırılmalıdır və həssas tətbiqləri həmin tuneldən kənar pəncərə boyunca bağlı saxlamalısınız; bu, yerli trafikin qorunmadan çıxdığı yeganə intervaldır. İdarə olunan daim işlək cihaz siyasəti sizin silməyiniz əvəzinə sahibinin dərc etdiyi proseduru istifadə etməlidir. Portal sertifikat xəbərdarlığı göstərirsə, dayanın: onu qəbul etmək sessiyanızı məkanın kəsmə proksisinə yönləndirir və o proksi göndərdiyiniz hər şeyi oxuya bilər. Android-də daim işlək VPN altındakı kilid tunel qalxmadan trafiki bloklayır və bəzi buraxılışlar portal axınını istisna edə bilmir; sizinki edə bilmirsə, kilidi söndürmək əvəzinə məkanın alternativ girişini və ya başqa cihazı istifadə edin. Apple-ın tələb üzrə qaydaları yoxlama uğur qazanana qədər tuneli rədd edəcək şəkildə yazıla bilər ki, bu otel şəbəkələrində istədiyiniz davranışdır.

Mövcud alətlərlə ardıcıllıqla yoxlayın. Tuneldən əvvəl yoxlamanı başlıqlar və gövdə hər ikisi görünən şəkildə işlədin və VPN nəqliyyatınızın ümumiyyətlə cavab alıb-almadığını izləyin:

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'

İcazədən əvvəl normal portal iki cavabdan birini verir: Location sahəsi giriş səhifəsinə işarə edən 302, ya da portal səhifəsi olan HTML gövdəli 200. Hansını aldığınızı qeyd edin. Yönləndirmə girişdən əvvəl uğursuzluq deyil; portal sizə hara getməli olduğunuzu deyir. Portal uğur bildirdikdən sonra əmri təkrarlayın və gövdəsi hərfi Success sözü olan 200 gözləyin. Yoxlamanı mənalı edən məhz bu sətirdir. Əgər host heç daxil olmadan əvvəl normal cavab verirsə, bu şəbəkədə kəsici portal yoxdur. Çəkidə icazədən əvvəlki atılma heç nə qayıtmayan gedən paketlərdir, işləyən yol isə eyni axına təxminən bir saniyə içində cavab göstərir. Qoşulun, sonra çəkilişi təkrarlayın.

Portal bəli dedikdən sonra tunel hələ də uğursuz olursa

Giriş uğuru icazə verilmiş nəqliyyat demək deyil. Bir çox məkan portala və adi gəzintiyə icazə verir, halbuki UDP-ni tamamilə bloklayır, bu da WireGuard və UDP OpenVPN-i sıradan çıxarıb TCP 443-ü işlək saxlayır. TCP 443 keçirsə və UDP keçmirsə, bu səhv konfiqurasiya etdiyiniz müştəri deyil, məkanın siyasətidir, buna görə nəqliyyatı dəyişin və ya məhdudiyyəti qəbul edib davam edin. Bundan sonra yenidən qoşulma hələ də uğursuz olursa, dəqiq xətanı saxlayın; o, ilişdiyiniz mərhələni adlandırır.

Digər uğursuzluqlar cihazda yaşayır. Köhnə MAC-a bağlı qalmış sessiya, öz icarəsi olan ikinci Wi-Fi adapteri və ya portalın sertifikat istisnasını keşləyən müştəri — bunların hər biri təmiz yenidən icazədən sonra da uğursuz ola bilər. Əlaqəni kəsin, yenidən icazə verin və müştəri parametrlərinə toxunmadan əvvəl bir dəfə cəhd edin. İzlədiyiniz komponentlərin arxasındakı arxitekturanı istəyirsinizsə, RFC 8952 oxumağa dəyər.

Portal özü icazə verməkdən imtina edirsə, problem hesab və ya cihaz bölgüsündədir və heç bir VPN parametri bunu düzəltməyəcək. VPN-in çıxış ölkəsini dəyişmək məkanın yerli giriş vəziyyətini sıfırlamır; o cədvəl seçdiyiniz serverə deyil, cihazınıza bağlıdır. Məkan operatorundan soruşun və ona vaxt verin, çünki baxacaqları şey sessiya cədvəlidir.

Növbəti səfərinizdən əvvəl üç şeyi yazın: sıfırıncı addım kimi portal səhifəsini, apardığınız hər cihaz üçün bloklamanı dayandırma addımını və həqiqətən sınaqdan keçirdiyiniz bir nəqliyyat ehtiyat variantını. On dəqiqə əvvəl işləyən tunel yenidən dayandıqda, ona bitmiş icazə kimi baxın və VPN profilinə toxunmadan əvvəl portalı yenidən yoxlayın.