Otel Wi-Fi'sinde OpenVPN bağlanmıyor mu? TCP 443'ü deneyin

İstemciyi açın, Bağlan'a basın ve ardından gelen iletişim kutusu yerine durum satırını okuyun. Otel, kampüs veya mobil ağdan sonra Bağlanıyor ya da Sunucu bekleniyor durumunda takılan bir profil genellikle yolun bir yerinde taşıma katmanını kaybetmiştir, kimlik bilgilerini değil. Bir sonraki yararlı adım, sunucuya dokunmadan önce o ağın ne taşıdığını öğrenmektir. Aynı profil başka bir yerde çalışana kadar hiçbir şeyi değiştirmeyin.

Önce telefon hotspot'undan test edin. Tünel orada açılıyorsa sunucu, sertifika ve hesap sorunsuzdur ve geriye kalan tek değişken önünüzdeki ağdır.

İstemciden başlayın: durum satırını okuyun

Durum satırı hangi aşamanın başarısız olduğunu söyler. Bağlanıyor'da takılan istemci hâlâ ana bilgisayar adını çözüyor ya da dış soketi açıyordur; Sunucu bekleniyor'a ulaşanın yolu vardır ama yanıtı yoktur; kimlik doğrulayıp sonra düşenin sorunu tamamen başkadır. İstemci günlüğü ve profilin kendi remote ile proto alanları istemcinin ne yapmaya çalıştığını gösterir, komut satırı istemcisinde --verb 4 aynı ayrıntıyı yazdırır. Bunu önünüzdeki ağla karşılaştırmak, 'VPN engellendi' ifadesini somut bir iddiaya dönüştüren şeydir.

Sonra ağı elinizdeki araçlarla yoklayın. nc -vzu 203.0.113.10 1194 bir UDP veri birimi gönderir, curl -v telnet://203.0.113.10:443 TCP el sıkışmasının tamamlanıp tamamlanmadığını bildirir ve HTTPS sayfası yükleyen bir tarayıcı yalnızca giden 443'ün o tek ana bilgisayara ulaştığını kanıtlar. Küçük yoklamalar VPN istemcisinin yanıtlayamadığını yanıtlar: hangi bağlantı noktası ve hangi protokol bu ağdan gerçekten çıkıyor.

Üç ağ davranışı istemciden aynı görünür ve farklı yanıtlar gerektirir. Giden 443 açık olabilir, yalnızca bir proxy'ye izin veriliyor olabilir veya 443 ne taşıdığını okuyamayan bir denetim kutusuna saydam olarak iletiliyor olabilir. Birincisi aşağıdaki profil değişikliğiyle, ikincisi proxy ayarlarıyla düzelir, üçüncüsü ise el sıkışmayı tamamlayıp denetçi akışı beğenmediğine karar verdiğinde takılabilir. Hangisiyle karşı karşıya olduğunuzu bilmek, on dakikalık bir değişiklikle yarım gün istemci yeniden kurma arasındaki farktır.

Dinleyiciyi ve profili birlikte taşıyın

Sunucu tarafında dinleyiciyi ağın izin verdiğine ayarlayın: sunucu yapılandırmasında port 443 ve proto tcp, ardından hizmeti yeniden başlatın ve soketi ss -lntp ile doğrulayın. İstemci tarafında profil de aynı fikirde olmalıdır, çünkü taşıma ve bağlantı noktası tünelin dışındadır: .ovpn içinde proto tcp ve port 443 ya da uygulamanın ayarlar ekranındaki karşılık gelen alanlar. Hâlâ UDP 1194'ü hedefleyen bir profil aynen önceki gibi başarısız olur ve zaten onarılmış bir güvenlik duvarını suçlama dürtüsü doğar. Aynı ana bilgisayar 443'te HTTPS'e de yanıt veriyorsa iki dinleyici o adresi ve protokolü paylaşamaz; VPN'e ikinci bir adres verin ya da önüne bir çoğullayıcı ayırıcı koyun.

İlk bağlantıyı iki uçta tcpdump -ni any port 443 ile izleyin. İstemciden çıkıp hiç ulaşmayan paketler ağın yine de filtrelediğini ya da profildeki adresin sandığınız olmadığını gösterir. Yanıtsız gelen paketler sizi sunucu günlüğüne geri gönderir; orada protokol uyuşmazlığı hemen atılmış bir paket olarak görünür.

Ağdan yalnızca bir proxy çıktığında

Bazı misafir ağları HTTP proxy dışında hiçbir şeye izin vermez; bu kapalı bir bağlantı noktasından farklı bir kısıttır ve OpenVPN'den fazlasını dışlar. Yalnızca PPTP, L2TP/IPsec veya çıplak IPsec konuşan istemcilerin oradan geçme yolu yoktur, çünkü o tasarımlar dış protokollerinin sunucuya doğrudan ulaşmasını bekler. OpenVPN bunu yapabilir; istemci profilinde http-proxy proxy.example.net 8080 ile, proxy bağlantı noktanıza CONNECT yöntemine izin veriyorsa. SOCKS proxy daha da kolaydır, çünkü içinde ne olduğuna bakmadan akışı iletir.

İstemcinin proxy desteği olmadığı yerde genellikle 443 üzerinden bir SSH tüneli kalır. İkinci bir katman ekler ve ağın işletmecisinin bu konuda bir görüşü olabilir, bu yüzden ona mimari değil tek bir yolculuk için köprü olarak bakın.

Yedek yolu tutmadan önce maliyetini hesaplayın

TCP içinde TCP'nin bilinen bir maliyeti vardır. Dış bağlantı TCP ve yük de TCP olduğunda, kaybolan bir segment her iki katmanda yeniden iletimi tetikler ve iç bağlantı göremediği bir kayıptan geri çekilir. Tarama bunu kaldırır; etkileşimli oturumlar ve aramalar bunu hisseder. TCP 443 dinleyicisini bunu isteyen ağlar için yedek olarak tutun ve UDP'yi hâlâ geçiren her şey için varsayılan bırakın.

Seçimi profil adına ve destek notlarına yazın: hangi bağlantı noktası, hangi protokol ve hangi ağ buna yol açtı. Ardından ağ yöneticisine bir sonraki donanım değişiminden sonra o bağlantı noktasının açık kalıp kalmayacağını sorun, çünkü sessizce kaybolan bir yedek yol hiç yedek olmamasından kötüdür.