İç içe VPN tünelleri: büyük paketlerde içteki neden takılır

DNS çözülüyor, SSH oturumu ayakta kalıyor, sonra büyük bir yükleme donuyor, oysa aynı ana bilgisayara ping hâlâ yanıt veriyor. Bu ayrım bozuk bir tünele değil, paket boyutuna işaret eder. İç içe tüneller buna hiçbir tünelin tek başına ulaşamayacağı boyutlarda ulaşır. İç oturum sağlam; ona artık sığmayan paketler veriliyor.

Yolun MTU'su gerçekte nereye gidiyor

Her kapsülleme, bir sonraki katman sırasını almadan önce bayt harcar. Bir Ethernet yolu dış pakete 1500 bayt sunar ve dış tünel, içindeki hiçbir şey adreslenemeden kendi payını alır. Tek bir tahmini ek yük değeri tam da önemli olan miktar kadar yanlış olacaktır.

Katmanları sırayla listeleyin: erişim yolu, dış taşıma, dış tünel, iç taşıma, iç tünel, uygulama. Her başlığı bir kez sayın ve UDP'yi tünelin kendi başlığından ve etiketinden ayrı tutun.

İki WireGuard katmanı, bir kez sayıldı

Bir IPv4 erişim yolu alın, içinde başka bir WireGuard tüneli olsun. Dış katman 20 bayt IPv4, 8 bayt UDP ve WireGuard veri başlığı ile kimlik doğrulama etiketi için 32 bayt harcar. Bunun içinde iç tünel, ikinci 32 baytlık WireGuard ek yükünden önce kendi 20 baytlık IPv4 başlığına ve 8 baytlık UDP başlığına ihtiyaç duyar. Kalan kısım bir IPv4 başlığı, bir TCP başlığı ve veriyi alır. Dış IPv6 yolu 20 yerine 40 harcar ve 1320 bırakır.

Aritmetik 1340 baytta sonlanır. Aynı kurallarla tek katman TCP yükü için 1400 bırakır, yani 1500 eksi 20, 8, 32, 20 ve 20, ve 60 baytlık fark tam olarak ikinci tünelin eklediği iç kapsüllemedir.

1400'ü iç içe bir yola uygulayın, iç tünel 60 bayt eksik kalır, paket bunlara ihtiyaç duyacak kadar büyüyene kadar görünmez. Dolgu ve protokolün kendi parçalama seçeneği sayıları yeniden kaydırır, bu yüzden tabloya güvenin.

MTU, MSS ve parçalama farklı yerlerde etkilidir

Arayüz MTU'su arayüzün ne yayacağını sınırlar, TCP MSS sıkıştırması ise bir TCP eşinin ne göndermeye istekli olduğunu değiştirir. Sıkıştırma TCP oturumlarını düzeltir ve büyük bir UDP datagramı için hiçbir şey yapmaz, bu yüzden bir düzeltme bir uygulamada başarılı görünüp sonrakini sessizce atlar. Protokolün kendi parçalama seçeneği kendi başarısızlıkları olan üçüncü bir koldur. Arayüz MTU'su yaygın ilk hamledir ve en kaba olanıdır.

Köprülü ve yönlendirilmiş tüneller farklı çerçeveler taşır, bu yüzden başka bir kurulumdaki sayılar nadiren aktarılır. Yolun MTU keşfi, RFC 8201 içinde açıklandığı gibi, yalnızca bağlı olduğu ICMP iletilerinin geçmesine izin verildiği sürece yardımcı olur.

Eksik kalan katmanı bulmak

Gereksinimler karşılaştırmaya izin veriyorsa, iç içe koymadan önce her tüneli ayrı ayrı doğrulayın. Sabit boyutlu bir sonda buna karar verir: ping -M do -s 1472 -c 3 10.8.0.1 o katmanın içinde tam 1500 baytlık bir IPv4 paketi gönderir. İkinci katmanı ekleyin ve aynı sondayı yineleyin, böylece her arıza bilinen bir değişikliğe ait olsun.

Bir aktarım takıldığında, belgelenmiş tek bir parametreyi her seferinde değiştirin ve başarısız olan boyutu kaydedin. Dönüş yolunu da denetleyin, çünkü iç içe rota yinelemesi paket boyutu sorununu bir öğleden sonraya mal olacak kadar yakından taklit edebilir. Filtrelenmiş bir ICMP yanıtı gerçek sınırı gizleyebilir, bu yüzden sonda akıl yürütmeden daha önemlidir.

Bütçeyi bir sonraki kişinin bulacağı yere yazın

Katman başına bir satırlık bir tablo bir başparmak kuralından daha uzun yaşar. Tünel şemasının yanında tutun ki kimse baskı altında aritmetiği yeniden yapmasın.

Daha çok tünel daha çok bağımlılık demektir, bu yüzden geri alma planı bütçenin yanında yerini hak eder. Sayılar hâlâ tutmuyorsa yeniden tahmin etmek yerine yolu ölçün. Amaç hatırlayacağınız değil, savunabileceğiniz bir sayıdır.