IPv4 yolda parçalar; IPv6 bunun yerine paket çok büyük mesajı gönderir

IPv6 arızaları, bunlara neden olan paket boyutundan çok daha sık olarak protokole yüklenir. İki aile gerçekten aşırı büyük bir paketi farklı ele alır ve bu farkı önemli kılan tüneldir. IPv4 yönlendiricileri kurallar izin verdiğinde paketi parçalayabilir, IPv6 yönlendiricileri ise yolda hiç parçalamamalıdır. IPv6 bunun yerine gönderene söyler ve gönderenin tepki vermesi beklenir. Sonrasında ters giden her şey o mesajın ulaşıp ulaşmamasına bağlıdır.

Her aile ne yapar

Tablo dört satırdaki mekanizmadır ve bir satır karışıklığın çoğunu açıklar.

IPv6'da yolda parçalama da, temizlenecek bir DF bayrağı da yoktur, bu yüzden paket çok büyük olduğunda dayanacak bir şey yoktur. Gönderene söylenmelidir ve gönderen buna inanmalıdır.

Tünel yolu sessizce daraltır

VPN, paket ana bilgisayardan ayrılmadan önce dış başlıklar ekler, şifreli durumda bütünlük verilerini de ekler. İç paket gördüğü arayüz MTU'suna sığabilirken dış paket bir sonraki bağlantının sınırını aşar, bu yüzden bu ilk olarak bir tünelde ortaya çıkar. Tünel arayüzünün MTU'sunu bilerek düşürün veya yolda TCP MSS'yi sıkın ve hangi sayıyı neden seçtiğinizi yazın.

ESP ek yükü kipe ve algoritmalara bağlıdır, bu yüzden doğru tünel MTU'su bir hesaplamadır, gelenek değil. Ne seçerseniz seçin, tam 1280 baytlık iç IPv6 paketine yer bırakmalıdır, çünkü her IPv6 bağlantısı bunu taşımak zorundadır. 1280 bayt IPv6 taşıyamayan bir tünel ayar sorunu değildir; o aile için kırık bir yoldur. Yalnızca IPv4 kullanan bir kurulumdan MTU değeri kopyalandığında ortadan kaybolan tam da bu kısıttır.

Belirti neden takılma gibi görünür

Arıza temiz bir hata değildir ve bu yüzden yanlış teşhis edilir. Bir TCP el sıkışması tamamlanır, küçük yanıtlar gelir ve büyük bir yanıt ya da büyük bir yükleme başlar başlamaz bağlantı durur, çünkü bunlar atılmaya yetecek kadar büyük ilk paketlerdir. SSH bağlanır ve sonra ilk büyük çıktıda takılır, bir sayfanın başlığı yüklenirken gövdesi hiç bitmez.

ICMPv6'nın paket çok büyük mesajları filtrelenirse gönderen bunu asla öğrenmez ve aynı boyutu tekrar tekrar dener. Bu yavaş bir yol değil kara deliktir ve imzası rastgele kayıp değil, yinelenebilir boyut sınırıdır. İlgili denetim trafiğine izin vermek çalışan bir IPv6 kurulumunun parçasıdır, nezaket değil.

Kendi yolunuzun bağlı olduğu mesajları kapatıp sonra sonucu IPv6 arızası olarak tanımlamayın. Aynı sav IPv4'ün Fragmentation Needed mesajları için de geçerlidir; onlar da güvenlik duvarı yazarları arasında aynı ölçüde sevilmez ve aynı ölçüde gereklidir.

Sınırı ölçün, sonra katmanı düzeltin

Tahmin etmek yerine doğrulayın: IPv4'te don't-fragment bayrağını, IPv6'da sabit yük boyutlarını kullanın ve yanıtların nerede durduğunu kaydedin. ping -M do -s 1472 ve ping -6 -s 1400 sorunun biçimini belirlemek için yeterlidir ve tracepath yol boyunca bulunan yol MTU'sunu bildirir.

Sonra o sayıya sahip katmanı düzeltin: tünel arayüzünün MTU'su, TCP için MSS sıkma veya yolun kendisi. IPv6 kuralının başvurusu RFC 8200'dir ve önlediği olaydan daha kısa bir okumadır.

Uygulamanın gerçekten kullandığı aileyi test edin, çünkü çift yığınlı bir ad bir ailede yanıt verip diğerinde vermeyebilir ve uygulama bir ağ değişikliğinden sonra geçiş yapabilir. Test ettiğiniz adresi yazın, çünkü A kaydına karşı bir sonuç AAAA kaydı hakkında hiçbir şey söylemez.

Boyut sınırını kanıt olarak görün

Yinelenebilir boyut sınırı, her seferinde aynı bayt sayısında, aynı kaynaktan tam olarak yeniden üretilen az sayıda ağ arızasından biridir. Bu onu gizem değil armağan yapar ve bir düzeltmenin umulmak yerine doğrulanabileceği anlamına da gelir.

Bulunan MTU'yu, yapılandırdığınız tünel MTU'sunu ve farkı kanıtlayan testi bilete yazın. Sonraki kişi başka bir bağlantıda aynı aritmetikle karşılaşacak.