Kimlik doğrulamayı geçen, bir ping taşıyan ve ardından ilk büyük aktarımda takılan tünel, bozuk bir VPN'in değil, eksik bir ICMP mesajının klasik işaretidir. Gönderen paketin çok büyük olduğunu hiç öğrenmez, aynı boyutu yineler ve uygulama bekler. Bunu düzeltmek güvenlik duvarı politikası kararıdır, istemciyi yeniden kurmak değil. Sıra önemlidir: boyut sınırının nerede olduğunu ölçün, sonra raporu yutan kuralı daraltın.

ICMP bu yolda gerçekte ne taşır

IPv4 yol MTU keşfi bir yönlendiricinin don't-fragment biti ayarlı paketin iletilemediğini bildirmesine dayanır. Bu rapor bir ICMP Fragmentation Needed mesajıdır ve o olmadan gönderenin segment boyutunu küçültmek için bir nedeni yoktur. IPv6 daha katıdır: yönlendiriciler geçiş sırasında parçalamaz, bu yüzden ICMPv6 Packet Too Big mesajı göndereni küçülten tek sinyaldir.

Her iki mesaj da kontrol düzleminin geri bildirimidir ve hiçbiri tanılama yankısı değildir. Ping'i engelleyen bir politika ile tüm ICMP'yi engelleyen bir politika kural listesinde benzer görünür ama ağda çok farklı davranır. İkincisi, doğru boyutlandırılmış bir tüneli zincirdeki en küçük halkadan büyük her şey için tek yönlü bir yola çevirebilir.

Bazı taşıma katmanları kendi keşiflerini sonda paketleriyle uygular, RFC 4821'in anlattığı gibi, ve bu geri bildirime daha az bağımlıdır. Bu, hangi taşımayı çalıştırdığınızı denetlemek için bir argümandır, her tünelin bağışık olduğunu varsaymak için değil.

MesajYoldaki amaçEngellenirse
ICMPv4 tip 3 kod 4Paket bir sonraki halka için çok büyüktüGönderen yinelemeye devam eder ve takılır
ICMPv6 tip 2Packet Too Big, IPv6 karşılığıAynı takılma, parçalama yedeği olmadan
ICMP tip 11Süre aşıldı, traceroute kullanırTanılama atlamaları kaybeder, trafik akmaya devam eder
ICMP yankı isteği ve yanıtıErişilebilirlik testiPing başarısız olur, yol iyi olabilir

Hata boyuta bağlıdır

Hatanın paket boyutuyla ilişkili olup olmadığını sorun. Giriş sayfası, DNS sorgusu ve kısa bir API çağrısı geçerken dosya yükleme, büyük bir yanıt veya görsel indirme takılır. Bu örüntü iki uç arasında bir yerdeki boyut sınırına işaret eder, kimlik doğrulamaya veya yönlendirmeye değil. Başarılı küçük bir ping, o sınırın nerede olduğu hakkında neredeyse hiçbir şey söylemez.

Tünelin içinde dikkate alınacak iki katman vardır: yük paketi ve dış kapsüllenmiş paket. İçteki gönderen doğru davranırken dış yol tünelin varsaydığından küçük olabilir, bu yüzden hem tünelin kendi MTU ayarı hem de altındaki fiziksel bağlantı önemlidir.

Kuralları düzenlemeden önce ölçün

don't-fragment biti ve kendi seçtiğiniz yük boyutuyla sonda yapın, sorunlu istemciden korunan bir adrese doğru:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472 baytlık yük artı 28 bayt başlık 1500 baytlık bir paket oluşturur. Büyük sonda parçalama hatasıyla başarısız olur ve küçük olan geçerse sınırı bulmuşsunuzdur; tünelin ek yükü için düzeltin ve çalışan boyut kararlı olana kadar yineleyin.

Sonra boşluğun raporun kendisi olduğunu doğrulayın. Sonda sessizce başarısız olursa, hata ve yanıt olmadan, mesaj büyük olasılıkla teslim edilmek yerine düşürülüyordur ve şüpheli kuraldır.

Kuralı daraltın, sonra görevi yeniden test edin

Düzeltme tüm protokole değil, belirli kontrol mesajlarına izin vermelidir. iptables ana bilgisayarında biçim türe özgü izindir; sözdizimini platformunuzda güvenlik duvarını yöneten şeye uyarlayın:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Yerel politika buysa yankı yanıtlarını engelli bırakın, çünkü yolun bunlara ihtiyacı yoktur. Sonra başlangıçta başarısız olan aktarımı yeni bir bağlantıdan yeniden test edin ve kural sayaçlarının mesajların geldiğini gösterdiğini doğrulayın.

Mesajlara izin verildikten sonra büyük aktarım hâlâ takılıyorsa kalan sınır başka bir yerdedir: çok yüksek ayarlanmış tünel MTU'su, paketleri yeniden yazan bir proxy veya raporlamak yerine düşüren bir ara kutu. ICMP kuralı gerekliydi, yeterli değildi.

İlgili makaleler