Yalnızca web ağında VPN engellendi mi? Katmanları tek tek ele alın

Tarayıcının çalıştığı ama her tünelin öldüğü bir kampüs veya otel ağı tek bir sorun değil, üst üste dört sorundur. Yol yalnızca TCP 443'e izin verebilir, kimlik doğrulamalı bir proxy isteyebilir, el sıkışmayı inceleyebilir ya da politika ile uzaktan erişimi doğrudan yasaklayabilir. Bunları sırayla ele almak, bir ağ kuralını düzeltmek için yeni istemci almanızı önler. Aşağıdaki kılavuz yaklaşık on dakika sürer ve hangi katmanın sizi reddettiğine dair yazılı bir yanıtla biter.

Hangi katmanın bağlantıyı reddettiğini kanıtlayın

VPN istemcisiyle başlamayın. Aynı konağa düz bir HTTPS isteğiyle başlayın ve zaman aşamalarını okuyun, çünkü başarısız olan aşama hangi cihazın sorumlu olduğunu söyler:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Yanıt yok ve connect süresi yoksa TCP hiç tamamlanmamıştır, yani devrede bir güvenlik duvarı, proxy gereksinimi veya yanlış hedef var. connect süresi olup tls süresi yoksa ortadaki bir şey bağlantıyı kabul edip el sıkışmayı durdurmuştur; denetleyen bir proxy istemci tarafından böyle görünür.

Şimdi gerçekte aldığınız sertifikayı inceleyin. Sunucuyla mı yoksa oturumu yeniden imzalayan bir ara kutuyla mı konuştuğunuzu anlamanın en hızlı yolu budur:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Veren satırını okuyun. Kendi CA'nız hizmete ulaştığınız anlamına gelir; kurumsal veya cihaz vereni, bir filtrenin bağlantıyı sonlandırdığı ve sırada ne olacağına karar verdiği anlamına gelir. Her iki çıktıyı da zaman damgasıyla kaydedin, çünkü aynı test bir saat sonra misafir ağında farklı bir yanıt verebilir.

Proxy'den haberdar istemci ilk paketi değiştirir, politikayı değil

Ağ, kimlik doğrulamalı bir proxy üzerinden CONNECT gerektiriyorsa VPN istemcisine bunu söylemek gerekir, yoksa yönlendiremediği bir adrese soket açmaya çalışır. Proxy'yi istemciden ayrı test edin, böylece başarısızlığın tek bir açıklaması olsun:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

İlk komut proxy'nin hedefi taşıyacağını kanıtlar. İkincisi istemciden 443'te TCP kullanmasını ister; çoğu yalnızca web yolunun en fazla ilettiği tek taşıma budur. İlki başarılı olup ikincisi hâlâ başarısızsa engel proxy değildir.

Bazı istemciler geçersiz kılma yerine işletim sisteminin proxy'sini okur, bazıları ikisini de okumaz. Sistem geneli bir ayarın geçerli olduğunu varsaymadan önce uygulamanın kendi belgelerine bakın. Uç noktayı proxy'nin hizmet vermediği bir çözümleyici üzerinden çözen istemci de burada başarısız olur; bu yüzden DNS değişikliği yalnızca bir dolambaç iken düzeltme gibi görünebilir.

Bu arada yönlendirme desenine de dikkat edin. Filtrelenmiş bir ağ, bir sağlayıcının algılama ana bilgisayar adına kendi bir şeyiyle yanıt verebilir; bu da istemcinin hangi proxy profilini seçtiğini değiştirir. Bu tuhaflığın etrafında bir süreç kurmayın. Siteye göre değişir, haber verilmeden değişir ve başkası için destekleyebileceğiniz bir şey değildir.

443 numaralı bağlantı noktasına erişilebilir, izin verilmez

Bir tüneli 443'te TLS'e sarmak erişilebilirliği çözer, başka hiçbir şeyi değil. Bağlantı noktasını denetleyen filtre geçirir; el sıkışmanın parmak izini alan filtre geçirmez ve şifreli istemci merhabası sunucu adını yalnızca iki uç da desteklediğinde gizler. Testi çalıştırın ve ummak yerine hangi tür filtrenin arkasında olduğunuzu öğrenin.

İnsanların sonradan keşfettiği bir performans maliyeti de var. Güvenilir bir taşımanın içindeki güvenilir taşıma kaybı büyütür, çünkü iç yığın dış yığının zaten yeniden gönderdiği segmentleri yeniden gönderir. Temiz bir bağlantıda kimse fark etmez. Tıkanık bir kampüs kablosuz ağında tünel tam da ona ihtiyaç duyduğunuz anda kullanılamaz hale gelir ve grafik, kasten hiçbir şey atılmadığı halde paket kaybı gibi görünür.

UDP genellikle ilk kurban olur ve bunu tahmin etmek yerine doğrulamak gerekir. TCP 443 çalışırken WireGuard veya varsayılan OpenVPN hiç el sıkışmayı tamamlamıyorsa ağ UDP'yi düşürüyordur ve hiçbir anahtar yenileme bunu değiştirmez:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Dün çalışan bir eşin yanındaki boş el sıkışma zaman damgası UDP'nin yanıtıdır. İki DNS sorgusu başka bir soruyu yanıtlar: yerel çözümleyici ile genel bir çözümleyici uç nokta adresi konusunda anlaşamıyorsa yönlendiriliyorsunuz ve taşıma argümanı yanlış.

Makineden gerçekte ne çıktığını doğrulayın

İstemci günlükleri istemcinin neye inandığını anlatır. Bir yakalama ağın ne gördüğünü anlatır ve ikisi arasındaki fark bu vakaların çoğunun çözüldüğü yerdir:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

SYN paketleri görüp SYN-ACK görmüyorsanız engel yukarıdadır ve istemci masumdur. Sunucunun olmayan bir adrese tamamlanmış el sıkışma görüyorsanız bir proxy veya araya girenle konuşuyorsunuz. Hiçbir şey görmüyorsanız herhangi bir sonuca varmadan önce doğru arayüzde yakaladığınızı kontrol edin.

Yuva listesi daha ince bir durumu yakalar: varsayılan rotayı zaten tutan ikinci bir tünel. Yönlendirme tablosu için kavga eden iki istemci, tam olarak engellenmiş bir ağ gibi görünen aralıklı arızalar üretir ve yakalama, beklemediğiniz bir arayüzden çıkan trafiği gösterir.

Geri alma ve saklamaya değer not

Değişiklikleri yaptığınız sıranın tersine geri alın. Proxy değişkenlerini kaldırın, elle başlattığınız istemciyi durdurun ve eklediğiniz her rota veya çözümleyici geçersiz kılmasını kaldırın:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Elle başlatılmış bir istemciyi çalışır bırakmak, bir dizüstü bilgisayarın bir sonraki ofis ziyaretinde bozuk ağla kalmasının yoludur. Kabuk profilinde bırakılan proxy değişkenleri haftalar sonra alakasız araçları bozar ve bunları hata ayıklayan kişi iki olayı birbirine bağlamaz.

Sonra dört satır yazın: ağ, zaman damgası, başarısız aşama ve gördüğünüz veren. Bir kampüste çalışıp sonrakinde başarısız olan bir yol normaldir ve bir sonraki kişi farkın proxy, çözümleyici ya da filtre mi olduğunu bilmelidir. Yanıt ağın uzaktan erişimi yasakladığıysa, orada durun ve okumadığınız bir politikaya dolambaç taşımak yerine yöneticiden desteklenen yolu isteyin.