OpenVPN 443’te hâlâ engelli mi? Ağın neyi incelediğine bakın

443 portu numarayı değiştirir, protokolün şeklini değil. Yol TLS’i inceliyor veya sonlandırıyorsa, sıradaki testler bir sarmalayıcı ve doğru ana bilgisayar rotasıdır.

Tünel ev hattından bağlanıp bir otel veya ofis ağında takılıyor ve sunucuyu 443 portuna taşımak hiçbir şeyi değiştirmedi. Bu sonuç bir şekle sahip olacak kadar yaygın: port kolay kısımdı ve kararın geri kalanı istemci ile sunucu arasında oturan her şeye ait. İki soru çoğu durumu çözer ve hiçbiri şifrelerle ilgili değildir. Ağ o adrese bir TLS el sıkışmasını kabul ediyor mu ve tünel ayaktayken istemci kendi sarmalayıcısına giden bir rotayı koruyor mu?

El sıkışma numaradan fazlasını ele verir

TCP 443 üzerindeki yerel VPN dinleyicisi ilk paketten itibaren kendi protokolünü konuşur. ClientHello'da bir sürüm alanı, rastgele bir değer ve uzantı listesi vardır ve birkaç yüz bayt okuyan bir cihaz hiçbir şeyin şifresini çözmeden farkı görebilir. Port numaralarını tatmin etmek ucuzdur ve filtrenin gerçekten denetlediği şey protokolün şeklidir. Kurallar genellikle protokol başına da yazılır, bu yüzden TLS'i inceleyen bir politika UDP hakkında hiçbir şey söylemez.

Geçerli bir TLS oturumu talep eden şeffaf bir vekil sunucu, bağlantıyı kurulum sırasında düşürür, çoğu zaman TCP el sıkışması tamamlandıktan sonra. Bu ayrıntı sonra önemlidir, çünkü istemci günlüğünün soket kurulduktan sonra durduğu anlamına gelir.

Akışı sarmalamak iki arıza noktası yaratır

stunnel gibi bir TLS sarmalayıcısı beklenen şekli geri getirir: istemci yerel bir dinleyiciye bağlanır, sarmalayıcı sunucuya 443 üzerinden gerçek bir TLS oturumu açar ve sunucudaki ikinci sarmalayıcı çözülmüş baytları VPN arka plan programına iletir. Dış oturum artık herhangi bir HTTPS bağlantısı gibi görünür. Sunucudaki VPN arka plan programı yalnızca loopback üzerinde dinlemelidir, çünkü sarmalayıcının dışında hiçbir şeyin ona ulaşması gerekmez.

Bu tasarım için üç ayrı şeyin hizalanması gerekir. İstemci profili yerel dinleyiciyi gösterir, sunucu sertifikası istemcinin doğruladığı adla eşleşir ve sunucu tarafındaki yönlendirme arka plan programının gerçekten kullandığı portu hedefler. Bunlardan herhangi birinde yanılırsanız bağlantı VPN katmanına ulaşmadan ölür. O zaman sertifika uyuşmazlığı VPN hatası olarak değil sarmalayıcı hatası olarak görünür ve bu yüzden iki günlüğü yan yana okumaya değer.

Sarmalayıcıya giden rota tuzaktır

Tünel kalktığında varsayılan rota içine bakar ve dış TLS oturumunun taşıdığı tünele girmeyen bir yola ihtiyacı vardır. Sıradan bir VPN istemcisi çevirdiği adresi korur; sarmalanmış istemci kendi loopback'ini çevirir, bu yüzden sarmalayıcının hedef adresi bu korumaya görünmez.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Kesin adresleri siz doldurursunuz ve rota bağlantının tüm ömrü boyunca var olmalıdır, yalnızca başlangıçta değil. Rotayı istemciden önce ekleyip sonra kaldıran küçük bir sarmalayıcı betiği, hatırlanan bir komuttan daha güvenilirdir.

Android'de bu istisnanın karşılığı uygulama başına bir ayardır: sarmalayıcı uygulamayı tünelden hariç tutun, böylece kendi trafiği mobil bağlantıdan çıksın. Hariç tutulmazsa sarmalayıcı kurmaya çalıştığı tünele yönlendirilir ve yeniden bağlanma döngüsü bir sunucu sorunu gibi görünür.

Bir şeyi değiştirmeden önce zamanlamayı okuyun

Her seferinde aynı aralıktan sonra ölen bir oturum kriptografik bir arıza değil bir politika imzasıdır ve uzun ömürlü akış sınırları tam olarak bu deseni üretir. El sıkışmasından hemen sonra sıfırlanan bir bağlantı, sertifika zincirini sevmeyen bir vekil sunucuya işaret eder.

Sıradan bir HTTPS sitesinin sertifika vericisini iki ağdan karşılaştırın. Kısıtlı ağda verici farklıysa, ortada bir şey TLS'i sonlandırıyor demektir ve hiçbir sarmalayıcı bu araya girmeyi değişmeden atlatamaz. Aynı karşılaştırma, engellemenin sunucu adınızı mı yoksa o adresteki her TLS oturumunu mu hedeflediğini söyler.

Gözlenen davranışı yazın: oturum ne kadar sürdü, soket açıldı mı, sarmalayıcı bir el sıkışması kaydetti mi. Bunların her biri sıradaki testi daraltır.

Aynı anda tek değişken deneyin

Önce UDP'yi denetleyin, çünkü bazı ağlar onu tamamen atar ve UDP arızası 443 hakkında hiçbir şey söylemez. Sonra sarmalayıcı olmadan TCP 443'ü, ardından 443 üzerindeki sarmalayıcıyı deneyin. Her adımda istemci günlüğünü okuyun ve davranış değişir değişmez durun.

Her denemede tek bir öğeyi değiştirin. Yeni bir port, yeni bir sarmalayıcı ve yeni bir şifre aynı koşuda olursa üçünden hangisinin önemli olduğunu söyleyemezsiniz.

İlgili makaleler