MTU kara deliği: küçük istekler neden çalışır ama yüklemeler neden takılır

Bir sayfa yüklenir, küçük bir API çağrısı döner, ardından bir dosya yüklemesi istemci pes edene kadar asılı kalır. Sunucu günlüğünde bunu açıklayan hiçbir şey yoktur, çünkü paketler yolun ortasında işe yarar bir yanıt geri gönderilmeden düşürülmüştür. Bu desen bir MTU kara deliğidir: gönderenin varsaydığından daha dar bir bağlantı, artı bunu söylemekten sessiz bir reddediş. Başarısız olan boyut tekrarlanabilir, ve onu teşhis edilebilir kılan da budur.

Deliği karaya çıkaran ne

Her bağlantının bir azami iletim birimi vardır ve sonraki atlamanın sınırından büyük bir paket ya parçalanmalı ya da bunu söyleyen bir ICMP iletisiyle reddedilmelidir. Yol MTU keşfi, o iletinin ulaşmasına ve ona uyulmasına bağlıdır. Onu süzmek ya da yok saymak, göndereni asla sığmayacak bir paketi yinelemeye bırakır.

Kapsülleme bunu VPN çevresinde yaygın kılar, çünkü tünel fiziksel bağlantı için zaten boyutlandırılmış bir pakete bir dış başlık ekler. İç paket 1500 baytta yasaldır, kapsüllenmiş olan değildir, bu yüzden küçük paketler geçerken o sınırda ölür. Tamamlanmış bir el sıkışma ve çalışan bir oturum açma sayfası yalnızca küçük paketlerin çalıştığını kanıtlar. Uygulamanın göndermeye çalıştığı en büyük paket önemli olandır.

Kırıldığı boyutu bulun

Parçalama yapmayan bir testle yük boyutunu ikili aramayla bulun, tünelin bir tarafındaki ana bilgisayardan diğer taraftaki ana bilgisayara. Geçen en büyük yük, kullanılabilir yol MTU'nuzdan başlık yükünün çıkarılmasıdır.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

1472 baytlık bir yük, IPv4 ve ICMP başlıklarının 28 baytı eklendiğinde temiz 1500 baytlık bir Ethernet yolundan geçer. Aynı test tünel açıldıktan sonra yalnızca daha küçük bir yükte başarılı oluyorsa, fark kapsülleme yüküdür ve tünel sınırı reddetme iletisinin üretilmesi gereken yerdir. Her iki sayıyı da, bağlanmadan önce ve sonra not edin, çünkü o çift kanıttır. Uygulama IPv6 kullanıyorsa testi onun için de yineleyin, çünkü başlık daha büyüktür ve başarısızlık eşiği kayar.

Tüneli suçlamadan önce kanıtları okuyun

Uzak uygulama hataları, tıkanıklık ve olağan kayıp da yüklemeleri durdurur, bu yüzden tek bir başarısız aktarım bir kara delik tanımlamaz. Onları ayıran şey boyut ilişkisidir: 1200 baytta yinelenebilir başarı ve 1400 baytta yinelenebilir durma, aynı yönde, aynı uç noktadan.

Her iki uçta alınan kayıt, büyük paketlerin çıkıp hiç varmadığını, aralarında hiçbir reddetme olmadığını gösterir. Sunucu yerine sınır cihazına bakmanın zamanı odur, çünkü sunucu gerçekte aldığı her isteği yanıtlıyor. Tıkanıklık da durdurur, ama farklı boyutları farklı zamanlarda durdurur ve bu başka bir imzadır.

Onarımı iki taşıma katmanında da doğrulayın

Desteklenen onarım, sınırın gerçek sınırı bildirmesine izin vermek ya da orada TCP'nin azami segment boyutunu sıkıştırarak çok büyük bir segmentin denenmemesini sağlamaktır. Ağdaki her MTU'yu düşürmek ya da güvenlik duvarını kapatmak belirtiyi gizler ve sonradan kimsenin akıl yürütemeyeceği bir yapılandırma bırakır.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Aynı boyut testiyle doğrulayın, sonra başarısız olan uygulamayla, ve ikinci bir protokolü kontrol edin, çünkü UDP uygulamaları TCP'nin segment boyutu düzeltmesini asla almaz. Özgün değerleri kayıtta saklayın, çünkü geri alınamayan bir onarım gerçekleşmeyi bekleyen ikinci bir sorundur. Boyut testi geçer ve yükleme hâlâ takılırsa, kara delik neden değildi ve değişikliği genişletmek yerine soruşturma ilerlemelidir.