OpenVPN profili evdə niyə işləyir, oteldə niyə uğursuz olur

Ofis Wi-Fi şəbəkəsi və otel otağı eyni noutbuka iki tamamilə fərqli şəbəkə verə bilər və aradakı profil bunu bilmir. Evdə işləyən konfiqurasiya icazəli yuxarı kanal, işləyən ad həlli və tunelin daşıdığı heç nə ilə toqquşmayan yerli alt şəbəkə fərz edir. Bu fərziyyələrin hər biri ayrıca pozula bilər.

Bunu sazlamağın faydalı yolu şəbəkəni dörd ayrı fakt kimi qəbul edib onları sıra ilə yoxlamaqdır. Əvvəlcə profil üzərində təxmin yürütmək adətən heç nəyi düzəltməyən və sübutu gizlədən dəyişiklik yaradır.

Dörd şəbəkə faktı məkanlar arasında dəyişir

Birinci fakt yerli şəbəkənin ümumiyyətlə sizi buraxıb-buraxmamasıdır. Giriş portalı cihazı giriş səhifəsinə buraxır və həmin səhifə tamamlanana qədər hər şeyi bloklayır, yəni profil nə qədər düzgün olsa da tunel başlaya bilməz.

İkincisi ad həllidir. DNS-i tutan portal hər sorğuya öz ünvanı ilə cavab verir, buna görə VPN host adı portalın ünvanına çevrilir və müştəri veb səhifəyə tunel qurmağa çalışır.

Üçüncüsü nəqliyyat filtrləməsidir. Yalnız gəzintiyə icazə vermək istəyən şəbəkələr TCP 443-ü istənilən təyinat yerinə keçirir və UDP daxil olmaqla demək olar ki, hər şeyi atır.

Dördüncüsü ünvanlamadır. Yerli alt şəbəkə tunelin arxasındakı şəbəkə ilə üst-üstə düşə bilər və ya yuxarı kanal ümumiyyətlə işlək IPv4 yolu verməyə bilər.

Ad həlli və giriş portalı

Profildəki host adını serverin rəqəmsal ünvanı ilə dəyişdirin və yenidən cəhd edin. Əgər IP qoşulur, ad isə qoşulmursa, günah ad həllindədir və profilin özü qaydasındadır.

VPN-ə toxunmazdan əvvəl brauzer açıb adi HTTP səhifəsini açmağa cəhd edin. Giriş səhifəsinə yönləndirmə portalın hələ gözlədiyini göstərir; onu tamamlayın, sonra yenidən qoşulun. Bir çox otel həm də sessiyanı bir neçə saatdan sonra bitirir, bu da giriş problemi yox, günorta kəsilməsi kimi görünür.

Rəqəmsal ünvan da uğursuz olursa, ad həlli izahat deyil, deməli nəqliyyata keçin. Sınadığınız ünvanı saxlayın, çünki o, növbəti yoxlamaya paketlərin maşından ümumiyyətlə çıxıb-çıxmadığını bildirir.

Nəqliyyat filtrləməsi: əvvəlcə UDP, ehtiyat kimi TCP 443

UDP 1194 üzərində OpenVPN axını otel firewall-nun tanıdığı heç nəyə bənzəmir, ona görə xəta vermədən atılır. Müştəri vaxt aşımı bitənə qədər yenidən cəhd edir və istifadəçi imtina yox, heç vaxt qurulmayan bağlantı görür. Bu cür davranan firewall-lar atmanı nadir hallarda görə bildiyiniz yerdə qeyd edir. İmtinanın olmaması özü işarədir.

TCP 443 etibarlı ehtiyatdır, çünki şəbəkə onu adi HTTPS-dən ayıra bilmir. Mövcud olduqda operatorun TCP profilini istifadə edin, çünki server də həmin nəqliyyat və portda dinləməlidir; yalnız müştərini dəyişmək fərqli növ uğursuzluq yaradır. TCP profili yoxdursa, portu redaktə edərək yenidən uydurmaq əvəzinə operatorla əlaqə saxlayın. Server tərəfi də razılaşmalıdır və uyğunsuzluq yenidən firewall problemi kimi görünür.

Performans qiymətini gözləyin. TCP-nin içində TCP itkili xəttdə təkrar ötürmələri gücləndirir, buna görə işləyən TCP tuneli tıxanmış otel şəbəkəsində yenə də yavaş hiss oluna bilər. Bu, əldə edilə bilənlik üçün mübadilədir, təqib edilməli qüsur deyil.

Ünvan toqquşmaları və IPv4-süz yuxarı kanallar

Tunel qurula və yenə də heç nə daşımaya bilər. Yerli LAN və uzaq şəbəkə 192.168.1.0/24 kimi prefiksi paylaşdıqda müştəri uzaq hostu birbaşa qoşulmuş sayır və paketi tunel əvəzinə yerli kanala göndərir. Simptom bir əlçatmaz alt şəbəkə ilə uğurlu bağlantıdır ki, bu da server tərəfində marşrut problemi kimi asanlıqla yanlış oxunur.

Daimi həll uzaq LAN-ı qeyri-adi özəl aralığa köçürməkdir. Evdə heç kimin istifadə etmədiyi aralıq seçmək, məsələn 10.42.0.0/24, problemi bir məkan üçün deyil, bütün gələcək məkanlar üçün qabaqlayır. Yerli müvəqqəti həll həmin oteldən, hotspotdan və ya marşrutlaşdırıcıdan qaçmaqdır ki, bu heç də həll deyil.

Mobil yuxarı kanallar iki variasiya əlavə edir. Operator səviyyəli NAT daxil olan bağlantıların çatmaması deməkdir; bu server yerləşdirirsinizsə vacibdir, çıxan müştəri üçün deyil. NAT64 tərcüməsi ilə yalnız IPv6 kimi qurulmuş APN isə real IPv4 yolu tələb edən müştərini uğursuz edə bilər və adi həll APN protokolunu IPv4 və ya ikiqat yığına dəyişməkdir.

Tunel qurulduqdan sonra simptomlar

Bağlantı qurub sonra səssizləşən tunel adətən keepalive və ya MTU problemidir, bloklanmış port deyil. Müəyyən dəqiqə sayından sonra düşən bağlantı keepalive və ya yenidən danışıq taymerinə işarə edir. Müştərini həmkarını yoxlamağa və cavablar dayandıqda yenidən başlamağa qurun, ping-lər işləyib böyük ötürmələr dayanırsa daha kiçik tunel MTU-sunu sınayın.

Kömək istəməzdən əvvəl üç şeyi yazın: sınadığınız ünvan və onun cavab verib-vermədiyi, istifadə etdiyiniz nəqliyyat və port, və uğursuz olan şəbəkənin yerli alt şəbəkəsi. Birlikdə bunlar ad həllini nəqliyyat filtrləməsindən və ünvan toqquşmasından ayırır ki, sübutla təmasda qalan səbəblər də bunlardır.