VPN MTU mitleri: paketleriniz neden küçülür ve yer nereye gider

Biri size VPN'in "MTU yüzünden paket kaybettiğini" söyler, tüneli 1400'e ayarlarsınız ve aktarım yeniden çalışır. Bu sonuç bir teşhis gibi hissettirir. Genellikle bu bir aritmetik tesadüfüdür: hiç tanımlamadığınız bir sınırın altına sığacak kadar küçük bir sayı seçtiniz ve aynı sınırla bir sonraki ağda farklı bir bütçeyle yeniden karşılaşacaksınız.

Bunun çoğuna iki efsane neden olur. Birincisi, tünel arayüzünün MTU'sunun yolun MTU'su olduğudur. İkincisi, kapsüllemenin "bir başlık" maliyeti olduğu ve PPPoE'nin saymaya değer hiçbir maliyeti olmadığıdır. İkisi de seçtiğiniz sayıyı keyfi gösteren ama aslında belirlenmiş olan biçimlerde yanlıştır.

Birinci efsane: tünelin MTU'su yolun MTU'sudur

Bir tünel arayüzüne ayarladığınız değer, uygulamanın aşağıya teslim edeceği en büyük iç paket hakkında yerel bir sözdür. Yolun gerçek kapasitesi sizinle uzak uç arasındaki her bağlantının bir özelliğidir ve bir yol değiştiğinde, bir mobil bağlantı devredildiğinde veya trafik başka bir peering aldığında değişebilir. Ayarlanmış 1500, ana makinenizin ne inşa edeceğini söyler, ağın ne taşıyacağını değil.

Yol MTU keşfi ikisini uzlaştırmak için vardır ve geri bildirime bağlıdır. IPv4'te tam boyutlu bir paketi iletemeyen bir yönlendirici ICMP "fragmentation needed" iletisi göndermelidir ve gönderici tahminini düşürür. IPv6'da karşılığı Packet Too Big iletisidir ve yönlendiriciler transit sırasında hiç parçalama yapmaz. Bu geri bildirim filtrelenirse gönderici yolun taşıyamayacağı paketler üretmeye devam eder ve hiçbir şey ona nedenini söylemez.

İkinci efsane: kapsülleme bir başlık maliyetindedir

Dış katmanları dürüstçe sayın. Dış IP başlığı IPv4'te 20 bayt veya IPv6'da 40 bayttır. NAT geçişi için UDP kapsüllemesi 8 ekler. Tünel protokolü kendi başlığını, bir başlatma vektörü veya nonce, şifrenin blok veya hizalama sınırına kadar dolgu, bir son ek ve bir bütünlük denetim değeri ekler. Protokole ve şifreye bağlı olarak toplam, iç paket başlamadan önce rahatça onlarca bayta ulaşır.

Sonra iç paketin kendi başlıklarını yeniden çıkarın. Tünel içindeki TCP segmenti kendi 20 baytlık IP başlığını ve 20 baytlık TCP başlığını taşır ve TCP'nin MSS'si tünelin nominal yükünden değil, MTU'dan türetilir. Bu yüzden ping daha küçük yükle başarılı olabilirken dosya aktarımı takılır: araçlar farklı şeyleri test eder ve yalnızca biri tam boyutlu bir TCP segmenti kullanır.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

İlk komut ayarlanmış tünel MTU'sunu bildirir. İki sonda 1472 baytlık bir yük gönderir, bu IPv4 ve ICMP başlıklarının 28 baytıyla 1500 baytlık bir pakettir, sonra daha küçüğü. Büyük sonda tamamen başarısız olur ve küçük olan başarılı olursa, boyuta bağlı bir arızanız vardır, genel bir yönlendirme sorunu değil.

Üçüncü efsane: PPPoE hâlâ size temiz 1500 verir

Geleneksel bir PPPoE erişim bağlantısı 1500 baytlık IP paketi taşımaz. PPPoE başlığı ve PPP protokol alanı Ethernet çerçevesi içinde 8 bayt tutar, bu da IP paketi için 1492 bırakır. Bu, RFC 2516'da açıklanan geleneksel sınırdır. Böyle bir bağlantı üzerinde VPN çalıştırırsanız, tünelin ek yükü 1500'den değil, o 1492'den gelir.

RFC 4638, hem erişim konsantratörünün hem de müşteri ekipmanının desteklediği durumlarda daha büyük bir PPP yükünün nasıl müzakere edileceğini tanımlar; bu yüzden "bu bağlantı PPPoE kullanıyor" ifadesi tek başına belirli bir sayıyı kanıtlamaz. Yerel bir ayar, ara bir cihazı hiç yapılandırılmadığı bir paketi kabul etmeye zorlayamaz, dolayısıyla yararlı soru etiketin ne söylediği değil, bağlantının gerçekte neyi müzakere ettiğidir.

Arıza neden seçici görünür

Küçük isteklerin başarılı olması ve büyük aktarımların takılması, yol MTU'sunun kara deliğinin klasik imzasıdır. El sıkışma, DNS sorgusu ve API çağrısı hepsi sığar; toplu aktarım tek bir bağlantıda ölen tam boyutlu segmentler üretir ve sorunu bildirmesi gereken ICMP iletisi asla gelmez. Bağlantı iyi görünür ve indirme askıda kalır, bu da insanları yol yerine sunucuya bakmaya yöneltir.

İkinci, ilgili hata üç sayıyı karıştırmaktır: arayüz MTU'su, TCP'nin MSS'si ve protokolün kendi parçalama veya dolgu ayarı. Bir yönlendiricide MSS sıkıştırma, göndericinin daha küçük segmentler kurması için duyurulan MSS'yi yeniden yazar; tünel MTU'sunu değiştirmez ve UDP trafiğine yardım etmez. Üçüne de aynı sayıyı vermek, iyi niyetli bir değişikliğin çalışan bir kurulumu bozma biçimidir.

Neyi, hangi sırayla değiştirmeli

Kanıtla başlayın. Yukarıdaki sondalarla arızanın boyuta bağlı olduğunu doğrulayın, sonra geçen en küçük boyutu ve başarısız olan en büyük boyutu bulun. Tüneli suçlamadan önce erişim bağlantısının gerçek MTU'sunu kontrol edin; bir PPPoE bağlantısı VPN'iniz ona dokunmadan önce bütçeyi sınırlar. Değişikliğin geri alınabilmesi için özgün değerleri not edin.

Sonra istemcinin belgelediği en küçük ayarlamayı uygulayın. Birçok istemci tünel MTU'su ve bir MSS düzeltme seçeneği sunar ve MSS seçeneği TCP için genellikle daha iyi bir kaldıraçtır çünkü her paketi küçültmeden göndericiye ulaşır. Aynı hedefi ve aynı aktarımı yeniden test edin ve üzerinde karar kıldığınız sayıları not edin. Bir erişim ağında çalışan tünel değeri evrensel bir sabit değildir ve sonraki sahanın kendi bütçesi olacaktır.