OpenVPN otel Wi-Fi şəbəkəsində qoşulmur? TCP 443-ü yoxlayın

Müştərini açın, Connect düyməsinə basın və ondan sonra gələn dialoqun əvəzinə status sətrini oxuyun. Otel, kampus və ya mobil şəbəkədən sonra Connecting və ya Waiting for server mərhələsində dayanan profil adətən nəqliyyat qatını yolun hansısa yerində itirib, etimadnamələrini deyil. Növbəti faydalı addım serverə toxunmazdan əvvəl o şəbəkənin nə daşıdığını öyrənməkdir. Eyni profil başqa yerdə işləyənə qədər heç nəyi dəyişməyin.

Əvvəlcə telefon hotspotundan sınayın. Tünel orada qalxırsa, server, sertifikat və hesab hamısı qaydasındadır və qalan yeganə dəyişən qarşınızdakı şəbəkədir.

Müştəridən başlayın: status sətrini oxuyun

Status sətri hansı mərhələnin uğursuz olduğunu deyir. Connecting-də ilişib qalan müştəri hələ də hostu həll edir və ya xarici soketi açır; Waiting for server-ə çatan müştərinin yolu var, cavabı yoxdur; autentifikasiyadan keçib sonra düşən müştərinin tamam başqa problemi var. Müştəri jurnalı və profilin öz remote və proto sahələri müştərinin nə etməyə çalışdığını göstərir, əmr sətri müştərisində --verb 4 eyni təfərrüatı çap edir. Bunu qarşınızdakı şəbəkə ilə müqayisə etmək «VPN bloklanıb» ifadəsini konkret iddiaya çevirən şeydir.

Sonra şəbəkəni artıq əlinizdə olan alətlərlə yoxlayın. nc -vzu 203.0.113.10 1194 UDP datagramı göndərir, curl -v telnet://203.0.113.10:443 TCP əl sıxışmasının tamamlanıb-tamamlanmadığını bildirir, HTTPS səhifəsi yükləyən brauzer isə yalnız çıxan 443-ün həmin bir hosta çatdığını sübut edir. Kiçik yoxlamalar VPN müştərisinin cavab verə bilmədiyi suala cavab verir: hansı port və protokol bu şəbəkədən ümumiyyətlə çıxır.

Üç şəbəkə davranışı müştəri tərəfindən eyni görünür və fərqli cavablar tələb edir. Çıxan 443 açıq ola bilər, yalnız proxy-yə icazə verilə bilər, ya da 443 daşıdığını oxuya bilməyən yoxlama qutusuna şəffaf şəkildə yönəldilə bilər. Birincisi aşağıdakı profil dəyişikliyi ilə, ikincisi proxy parametrləri ilə düzəlir, üçüncüsü isə əl sıxışmasını tamamlayıb sonra yoxlayıcı axını bəyənmədiyinə qərar verəndə dayana bilər. Hansı ilə üzləşdiyinizi bilmək on dəqiqəlik dəyişikliklə müştəriləri yenidən quraşdırmaqla keçən bir günorta arasındakı fərqdir.

Dinləyicini və profili birlikdə köçürün

Server tərəfində dinləyicini şəbəkənin icazə verdiyinə qurun: server konfiqurasiyasında port 443 və proto tcp, sonra xidməti yenidən başladın və soketi ss -lntp ilə təsdiqləyin. Müştəri tərəfində profil razılaşmalıdır, çünki nəqliyyat və port tuneldən kənarda yerləşir: .ovpn faylında proto tcp və port 443, ya da tətbiqin parametrlər ekranındakı uyğun sahələr. Hələ də UDP 1194-ə yönəlmiş profil əvvəlki kimi uğursuz olur və yem artıq düzəldilmiş firewall-u günahlandırmaqdır. Eyni host 443-də HTTPS-ə də cavab verirsə, iki dinləyici həmin ünvanı və protokolu paylaşa bilməz; VPN-ə ikinci ünvan verin və ya qabaqda demultiplekser qoyun.

İlk bağlantını hər iki tərəfdə tcpdump -ni any port 443 ilə izləyin. Müştəridən çıxıb heç vaxt çatmayan paketlər şəbəkənin yenə də filtrlədiyini, ya da profildəki ünvanın güman etdiyiniz ünvan olmadığını bildirir. Cavabsız gələn paketlər sizi server jurnalına qaytarır, orada protokol uyğunsuzluğu dərhal atılmış paket kimi görünür.

Şəbəkədən yalnız proxy çıxanda

Bəzi qonaq şəbəkələri HTTP proxy-dən başqa heç nəyə icazə vermir, bu bağlı portdan fərqli bir məhdudiyyətdir və OpenVPN-dən çoxunu istisna edir. Yalnız PPTP, L2TP/IPsec və ya təmiz IPsec danışan müştərilərin ondan keçmək üçün yolu yoxdur, çünki o dizaynlar xarici protokollarının serverə birbaşa çatmasını gözləyir. OpenVPN bacarır, müştəri profilində http-proxy proxy.example.net 8080 ilə, bir şərtlə ki proxy portunuza CONNECT metoduna icazə versin. SOCKS proxy daha asandır, çünki axını içindəkinə baxmadan ötürür.

Müştərinin proxy dəstəyi olmadıqda, 443 üzərindən SSH tuneli adətən qalan variantdır. O, ikinci qat əlavə edir və şəbəkə operatorunun bu barədə fikri ola bilər, ona görə ona memarlıq kimi deyil, bir səfərlik körpü kimi yanaşın.

Ehtiyat variantı saxlamaqdan əvvəl qiymətini hesablayın

TCP içində TCP-nin məlum qiyməti var. Xarici bağlantı TCP, yük də TCP olduqda, itirilmiş seqment hər iki qatda yenidən göndərməni işə salır və daxili bağlantı görə bilmədiyi itkidən geri çəkilir. Brauzinq bunu keçirir; interaktiv sessiyalar və zənglər bunu hiss edir. TCP 443 dinləyicisini tələb edən şəbəkələr üçün ehtiyat kimi saxlayın və hələ də keçirən hər şey üçün UDP-ni standart buraxın.

Seçimi profil adında və dəstək qeydlərində yazın: hansı port, hansı protokol və hansı şəbəkə buna səbəb oldu. Sonra şəbəkə administratorundan soruşun ki, o port növbəti avadanlıq yenilənməsindən sonra açıq qalırmı, çünki səssizcə yox olan ehtiyat variant heç ehtiyat variant olmamasından pisdir.