UDP'yi ISP mi engelliyor, yoksa tünelin içindeki uygulama mı?

Birisi VPN'in „UDP'yi engellediğini“ bildiriyor ve bu cümle birbirinden tamamen farklı iki iddiayı saklıyor. Biri erişim ağının görebildiği taşımayla, diğeri bir uygulamanın tünel içinde şifresi çözüldükten sonraki paketleriyle ilgili. Şifrelenmiş bir tünel dışarıdan hiçbir anahtar olmadan filtrelenebilir ve iç UDP uygulaması filtrelemeyle hiç ilgisi olmayan nedenlerle başarısız olabilir. Kanıt toplamaya başlamadan önce hangi iddiayı test ettiğinize karar verin.

İki başlık, tek kelime

NAT-traversal kullanan bir IPsec kurulumunda dış paket, iki VPN uç noktası arasında adreslenmiş UDP'dir, genellikle 4500 numaralı bağlantı noktasında. Bunun içinde şifrelenmiş yük, tünelin ilettiği her şeyi taşır ve bu da kendisi TCP veya UDP olabilir. Dolayısıyla UDP kelimesi iki kez, farklı anlam ve farklı görünürlükle ortaya çıkar.

Ara bir ağ dış başlığı görür, iç başlıktan hiçbir şey görmez. Dış akışa izin verebilir, şekillendirebilir veya düşürebilir ve bunun için hiçbir şeyin şifresini çözmesi gerekmez. İki iddianın karışmasının tüm nedeni bu asimetridir: aynı kelime hem ağın filtrelediğini hem de uygulamanın gönderdiğini tanımlar. Bir bulguyu kaydettiğinizde kelimenin yanına katmanı yazın, karışıklık büyük ölçüde kaybolur.

İç başlık ancak alıcı uç noktada, şifre çözüldükten sonra görünür hale gelir. O andan itibaren paket, yollar, politika ve uç noktanın kendi filtrelemesine bağlı olarak diğerleri gibi iletilir. Bunlar farklı cihazların verdiği ayrı kararlardır.

Ağın hâlâ görebildikleri

Şifreleme yükü ve iç taşıma başlığını gizler, bir akışın var olduğu gerçeğini değil. Uç nokta adresleri, bağlantı noktaları, paket boyutları ve zamanlama görünür kalır ve bunlar trafiği sezgisel olarak sınıflandırmaya veya belirli bir hedefi engellemeye yeter.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

İlk yakalama fiziksel arayüzdeki dış akışı, ikincisi tünel arayüzündeki iç akışı gösterir. İkisini aynı anda çalıştırmak soruyu doğrudan yanıtlar: dış akış varsa ve iç akış yoksa, uygulama tünele hiçbir şey göndermemiştir. İkisi de varsa ve hiçbir şey dönmüyorsa, sorun tünelin ötesinde, hedefte veya dönüş yolundadır.

RFC 3948 dış UDP kapsüllemesini tanımlar ve ESP belirtimi bunun içindeki korumalı düzeni tanımlar. İki belgenin hiçbiri bir erişim ağının dış akışı geçireceğini vaat etmez, bu yüzden iç akış hakkında herhangi bir teoriden önce dış demet üzerinde bir erişilebilirlik testi çalıştırmaya değer. Engellenen dış demet, hiç oluşmayan bir tünel üretir; oluşup sonra bir uygulamayı kaybeden bir tünel değil.

Çalışan bir tünelin içinde bir UDP uygulaması neden başarısız olur

Web uygulamasını taşıyan ama UDP uygulamasını taşımayan bir tünelin birkaç makul açıklaması vardır ve iç protokolün ISP tarafından filtrelenmesi ilki değildir. En yaygını kapsamdır: iki uygulama aynı tünele birlikte girmez, çünkü UDP hedefine giden yol yoktur veya istemcinin bölünmüş tünel kuralları onu dışlar.

İkincisi uç noktadır. Protokol listesine izin veren bir VPN sunucusu, hedefteki bir güvenlik duvarı veya beklenen bağlantı noktasında hiç dinlemeyen bir hizmet, hepsi ağ engellemesine tıpatıp benzeyen bir zaman aşımı üretir.

Üçüncüsü paket boyutudur. UDP uygulamaları genellikle bir web isteğinden daha büyük datagramlar gönderir ve kapsülleme kullanılabilir MTU'yu azaltır, bu yüzden başarılı bir el sıkışmanın ardından ilk tam boy yükte sessizlik gelebilir. Küçük paketler geçip büyükler kaybolduğu için bu örüntüyü engelleme olarak yanlış okumak kolaydır. Hızlı bir MTU yoklaması bunu bir dakikadan kısa sürede çözer ve yanıt genellikle ağ filtresi değil, daha küçük bir yük veya düzeltilmiş MSS olur.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

İlk komut, büyük bir paketin parçalanma kapalıyken yolu geçip geçmediğini test eder; bu da MTU sorununu hızla ortaya çıkarır. İkincisi küçük ve sınırlı bir UDP akışı gönderir ve kayıp ile jitter bildirir. Başlayıp sonra duran bir akış engellemeye değil boyuta işaret eder.

Protokolü değil katmanı bildirin

Bulguyu üç biçimden birinde yazın: dış teslim başarısız oldu, iç yönlendirme başarısız oldu veya uygulama başarısız oldu. Her birinin sahibi farklıdır ve bunları karıştırmak kaydı yanlış ekibe gönderir.

Yerel bir bağlantı noktasını değiştirmek uzak uçta eşleşen bir dinleyici oluşturamaz, bu yüzden yardımcı görünen istemci tarafı çözümü genellikle özgün hedefin yanlış olduğunun kanıtıdır. Aynı şekilde, sağlanan alternatif profil erişilebilirlik hakkında bir şey kanıtlar ve uygulamanın doğru yapılandırılıp yapılandırılmadığı hakkında hiçbir şey kanıtlamaz.

Çıkarımı gözlemden ayrı tutun. Trafik analizi bir akışın ne olduğunu şifresini çözmeden önerebilir ve bu yararlı bir bulgudur, ancak iç başlığı okumakla aynı iddia değildir. Hangisine gerçekten sahip olduğunuzu belirtin.