VPN üzerinden yol MTU keşfi: boyutlandırma ve ICMP boşluğu

Bir tünel el sıkışmasını tamamlar, küçük istekler geri döner ve ilk büyük aktarım takılır. Bu örüntü, verimden çok önce yol MTU'suna işaret eder. Rota boyunca her bağlantı paket boyutunu sınırlar ve kapsülleme bu iznin bir kısmını dış başlıklara harcar, bu yüzden iç paket ham yolun ima ettiğinden küçük olmalıdır. Arıza sessizdir ve onu teşhis etmeyi pahalı kılan da budur.

Yol MTU'su gerçekte neyi ölçer

Yol MTU'su iki ana bilgisayar arasındaki rotadaki en küçük bağlantı MTU'sudur, yerel arayüzünüze basılmış MTU değildir. Yerel değer tahminin başladığı noktadır ve yolun nerede bitmesi gerektiğine yol karar verir. Bu yüzden aynı tünel bir erişim ağında çalışırken diğerinde takılabilir: rota değişti, yapılandırma değil. Bir kez ölçüp her yerde varsaymak bu sorunu canlı tutan hatadır.

Bir tünel için önemli olan sayı iç MTU'dur, yani dış yolun izni eksi kapsüllemenin tükettiği miktar. WireGuard bir dış IP başlığı ve bir UDP başlığı ekler; diğer taşımalar kendi başlıklarını ekler. İç boyutu çok yükseğe ayarlayın, tam boyutlu her paket hiç gerçekleşmeyebilecek bir parçalanmaya ihtiyaç duyar.

Bir tünel kullanılabilir paketi neden küçültür

Tünel arayüzü fiziksel bağlantının MTU'sunu korursa, her büyük paket rotanın aşağısında birinin onu parçalamaya istekli olmasına bağlıdır. IPv4 bunu ilke olarak kabul eder, ancak parçalamaması söylenen bir yönlendirici bunun yerine hata döndürür. IPv6 yönlendiricileri geçiş sırasında asla parçalamaz, bu yüzden aynı ayar adres ailesine göre farklı davranır. Her durumda gönderen, bir şey geri bildirene kadar hiçbir şey öğrenmez.

Pratik sonuç, el sıkışmaya sığan ama yüke sığmayan bir boyuttur. Bir TLS ClientHello veya DNS sorgusu küçülmüş bir yolu dokunulmadan geçecek kadar küçüktür, oysa toplu bir aktarım değildir. Bu yüzden belirtiler belirli ana bilgisayarların değil, belirli işlemlerin çevresinde toplanır.

Keşif ancak geri bildirim ulaştığında işe yarar

IPv4 keşfi don't-fragment bitine dayanır: paketi iletemeyen bir yönlendirici, sonraki atlamanın MTU'suyla birlikte ICMP fragmentation-needed döndürür ve gönderen tahminini düşürür. IPv6 bunun yerine Packet Too Big mesajları kullanır, çünkü yönlendiriciler geçiş sırasında parçalamaz. Her iki mekanizma da mesajın gönderene geri dönüş yolunu bulacağını, tünelden ve dönüş yolundaki herhangi bir güvenlik duvarının ötesinden geçeceğini varsayar. Bu varsayım çöktüğünde, gönderen yolun taşıyamayacağı bir boyutu tekrar tekrar denemeye devam eder.

echo request ve echo reply'ye izin veren bir güvenlik duvarı mutlaka bu hata türlerine izin vermiş değildir. ICMP bir ailedir ve burada önemli olan üyeler hatalardır, echo çifti değil. Tünelin iki ucunda ve aralarındaki rotada denetim trafiği ilkesini kontrol edin ve her yerde her ICMP türüne izin vermek yerine platformun desteklediği rehberi izleyin.

Aynı filtreleme tünelin içinde de olabilir. İç yol hatayı düşürüp dış yol onu taşıyorsa, gönderen kapsüllenmiş trafiğin asla gerçekte görmediği bir sınıra uyum sağlayabilir.

Bir sayı tahmin etmek yerine yolu test edin

Hedefi, erişim ağını ve tüneli sabit tutun, yalnızca paket boyutunu değiştirin. MTU ipucuyla başarısız olan bir don't-fragment testi size sonraki atlamanın sınırını verir; bir boyut geçene kadar yineleyin ve hem boyutu hem de adres ailesini kaydedin.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Sığan bir ping, gerçek bir uygulamanın tam boyutlu segmentlerinin sığdığını kanıtlamaz, bu yüzden testi gerçekten başarısız olan aktarımla tekrarlayın. Çalışan en büyük testi yapılandırdığınız tünel MTU'suyla karşılaştırın ve iki sayıyı notlarınızda ayrı tutun. Aralarında yaklaşık bir başlık kadar fark varsa, kapsülleme ek yükünü buldunuz, bir arıza değil.

RFC 4821'de açıklanan PLPMTUD yukarı doğru test eder ve iletilen hatalara güvenmek yerine taşıma onaylarını kullanır. ICMP'yi filtreleyen yollarda yardımcı olur, ancak destek yığına ve uygulamaya göre değişir. Bir TCP akışı kendi kendine toparlanabilirken sabit datagram boyutlu bir UDP uygulaması başarısız olmaya devam eder.

Bir değer seçin ve gerekçeyi kaydedin

Tünel MTU'sunu düşürmek hem bir teşhis hem de meşru bir düzeltmedir yolu bildikten sonra. Hangi yolun ve hangi geri bildirim mekanizmasının devrede olduğunu bilmenin yerini tutmaz, çünkü mobil bağlantı için ayarlanmış bir değer fiber bağlantıda gereksiz yere küçük olacaktır. Seçilen boyutu, onu gerekçelendiren testi ve geri alma adımını kaydedin.

IPv4 mekanizması RFC 1191 ve IPv6 paketleme rehberi RFC 8201'de açıklanmıştır; ikisini de anmak sonraki mühendisin varsayımı yeniden türetmesini engeller. Aktarım seçtiğiniz boyutta hâlâ takılıyorsa sayıyı düşürmeyi bırakın ve sonraki katmana bakın. Her boyutta başarısız olan bir yol MTU sorunu değildir.