IPv6 paketi çok büyük: büyük VPN aktarımları neden takılır

Ping çalışıyor, tarayıcı küçük bir sayfayı yüklüyor ve dosya aktarımı takılıyor; hepsi aynı tünelde IPv6 üzerinden. Bu desen genellikle tünelin yavaş olduğu değil, gönderenin yolun gerçek boyutunu hiç öğrenmediği anlamına gelir. IPv6, yönlendiricilerin sorunu Packet Too Big mesajıyla bildirmesini bekler ve kapsülleme, paket dış ağa ulaşmadan önce ek yük getirir. Bu mesaj filtrelenirse, gönderen geçemeyecek bir boyutu tekrarlamaya devam eder.

Küçük istekler, büyük takılmalar

Bir tünel her paketi bir başka başlığa sarar, bu yüzden içeride kullanılabilir boyut dışarıdaki boyuttan küçüktür. Kapsülleme öncesinde fiziksel bağlantı için ölçülen paket sonradan çok büyük hale gelir. IPv4 yönlendiricileri yol boyunca parçalayabilir, IPv6 yönlendiricileri ise bunu gönderen adına yapmaz, bu yüzden gönderen kendisi uyum sağlamak zorundadır. Ve bu uyum tamamen geri bildirimin alınmasına bağlıdır.

Tek bir kayıp mesaj klasik belirtiyi üretmeye yeter: el sıkışmalar ve küçük yanıtlar başarılı olur, dizin listesi veya yükleme ise her seferinde aynı noktada takılır. Kullanıcılar bunu yavaş VPN olarak tanımlar ve günlükler kimlik doğrulamada hiçbir sorun göstermez. İki gözlem de doğrudur ve hiçbiri arızanın yerini bulmaz.

Packet Too Big geri bildirimdir, trafik değil

ICMPv6 Packet Too Big mesajı bir sonraki atlamanın kabul edebileceği boyutu taşır ve gönderen bunu tahminini düşürmek için kullanır. Onu filtrelemek, yol tabelasını kaldırıp sonra sürücüleri suçlamak gibidir. Tüm ICMPv6'yı düşüren bir kural katı görünür ama buna ihtiyaç duyan her bağlantıda yol keşfini bozar. Mesaj, yol hakkında denetim bilgisidir, uygulama yükü değildir.

Seçici filtreleme hâlâ makuldür. Yankı istekleri ve komşu keşfi, hata mesajlarından farklı bir rol oynar ve bir politika onları farklı ele alabilir. Tüm protokolü kabul etmek ya da atlamak yerine platformun belgelenmiş filtreleme rehberini izleyin, çünkü RFC 8201 bu geri bildirimin keşfi nasıl yönlendirdiğini tanımlar.

İki adres ailesini ayrı ayrı test edin

IPv6'yı tek başına test edin, çünkü başarılı bir IPv4 aktarımı IPv6 yolu hakkında hiçbir şey kanıtlamaz. Ardından büyük aktarım takılırken denetim mesajlarını yakalayın. İki kayıt birlikte ya geri bildirimin çıktığını gösterir ya da hiç ulaşmadığını kanıtlar.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Prob, do-not-fragment biti ayarlanmış bir paket gönderir ve başarısız olduğu boyutu bildirir; tünelin sığdırması gereken sayı budur. Yol sorgusu hedefi taşıyacak arayüzü adlandırır, böylece hangi bağlantının MTU'sunun geçerli olduğunu bilirsiniz. Yakalama, ICMPv6 tip 2'yi, yani Packet Too Big mesajını filtreler ve bu ana bilgisayara ulaşıp ulaşmadığını gösterir. Mesaj yakalamada görünür ve aktarım hâlâ takılırsa, gönderen onu yok sayıyordur; bu da incelemeyi ağdan yığına taşır.

Tünel boyutunu ancak kanıtlardan sonra değiştirin

Tünelin MTU'sunu düşürmek filtrelenmiş bir mesajı gizleyip belirtiyi ortadan kaldırabilir, ama her pakette daha fazla ek yük pahasına. Bu bir geçici çözüm, teşhis değil ve yakalamanın yerini almak yerine onu izlemelidir. Rastgele düşük bir değer de görünürde hiçbir şeyi bozmaz, bu yüzden yapılandırmalarda yıllarca kalır. Onu bilinçli olarak değiştirin, değeri kaydedin ve hangi ölçümün bunu haklı çıkardığını not edin.

Ağ geçidini siz yönetiyorsanız, güvenlik duvarını kapatmak yerine mesajı düşüren kuralı inceleyin. Düzeltilmiş tek bir kural, bir politika istisnasından daha dardır ve sonradan savunması çok daha kolaydır. Aynı mantık zaman aşımları için de geçerlidir: her takılma bir boyut sorunu değildir ve ikisini ayıran şey yakalamadır.