MTU Sorunları: Paket Boyutu ve Fragmentasyon Problemlerini Çözme
Ağ sorunlarının en sinir bozucu ve en çok gözden kaçan nedenlerinden biri MTU sorunlarıdır. Bağlantı var, ping atıyorsunuz, DNS çalışıyor ama bazı siteler açılmıyor, VPN üzerinden dosya transferi yarıda kesiyor ya da SSH bağlantısı küçük komutlarda çalışıyor ama büyük veri göndermek istediğinizde donuyor. Tüm bu belirtiler sizi saatlerce uğraştırabilir çünkü sorun ilk bakışta hiç MTU’ya benzemiyor. Bu yazıda MTU nedir, fragmentasyon nasıl çalışır, sorunlar neden çıkar ve nasıl teşhis edip çözersiniz, bunları gerçek dünya örnekleriyle anlatacağım.
MTU Nedir ve Neden Önemlidir?
MTU (Maximum Transmission Unit), bir ağ arayüzünün tek seferde iletebileceği maksimum paket boyutunu byte cinsinden ifade eder. Ethernet için bu değer varsayılan olarak 1500 byte‘tır. Eğer gönderilecek veri bu sınırı aşıyorsa iki şey olabilir: ya paket parçalanır (fragmentasyon) ya da paket düşürülür.
Sorun şuradan kaynaklanıyor: Modern ağ altyapıları genellikle katman katman oluşur. Şirket ağınız, ISP’niz, üzerinden geçtiğiniz tünel protokolleri (VPN, GRE, PPPoE) her biri payload’a kendi header’larını ekler. Bu da efektif kullanılabilir MTU’yu düşürür.
Mesela PPPoE bağlantıları 8 byte header ekler, bu yüzden DSL hatlarında MTU genellikle 1492 olarak yapılandırılır. OpenVPN ya da WireGuard tünellerinde ek overhead daha da yüksektir. Eğer bu ayarlamalar yapılmazsa paketler ya fragmentasyona uğrar ya da “DF bit” (Don’t Fragment) set edilmişse direkt düşer.
Fragmentasyon Nasıl Çalışır?
IP katmanı, büyük bir paketi iletmek zorunda kaldığında onu daha küçük parçalara böler. Her fragment, bağımsız bir paket olarak iletilir ve karşı tarafta yeniden birleştirilir. Teoride bu güzel bir mekanizma ama pratikte ciddi sorunlar yaratır.
Öncelikle performans düşer. Fragmentasyon işlemi işlemci zamanı harcar, her fragment ayrı ayrı iletilmeli ve karşı tarafta buffer’da tutularak reassembly beklenmelidir. Eğer fragmentlerden biri kaybolursa tüm paket yeniden gönderilmek zorundadır.
Daha büyük sorun şu: ICMP Path MTU Discovery (PMTUD) mekanizması, ağ üzerindeki en küçük MTU değerini keşfetmek için çalışır. Sender tarafı büyük bir paket gönderir, DF biti set ederek “bunu parçalama” der. Yol üzerindeki bir router paketin boyutunu aşıldığını görünce ICMP Type 3, Code 4 (Fragmentation Needed) mesajı gönderir. Böylece sender MTU değerini aşağı çeker. Ama eğer bu ICMP mesajları firewall tarafından bloke ediliyorsa sender hiç haber alamaz ve bağlantı tamamen donabilir. Buna Black Hole Routing denir.
Belirtiler: MTU Sorununu Nasıl Tanırsınız?
MTU sorunlarının en tipik belirtileri şunlardır:
- Küçük web sayfaları açılıyor ama büyük ve içerik zengini sayfalar takılıyor
- SSH bağlantısı kuruluyor, komutlar çalışıyor ama
scpya da büyük dosya transferi başlamıyor - VPN bağlandıktan sonra bazı servisler çalışırken diğerleri yanıt vermiyor
- Ping çalışıyor ama HTTP/HTTPS bağlantısı kurulamıyor
curlya dawgetile küçük dosyalar iniyor, büyükler duraksıyor- IPsec tüneli üzerinden bağlantı var ama veri akışı yok
Bu belirtilerin ortak noktası şu: küçük paketler geçiyor, büyük paketler geçmiyor. Bu pattern’i kafanıza kazıyın, ileride çok işinize yarayacak.
Teşhis Araçları ve Teknikleri
ping ile MTU Testi
En temel araç ping‘in kendisidir. DF bitini set ederek farklı boyutlarda paket göndererek maksimum çalışan boyutu bulabilirsiniz.
# Linux'ta DF bit set ederek ping
ping -M do -s 1472 8.8.8.8
# -M do: Don't Fragment
# -s 1472: payload boyutu (1472 + 28 byte IP/ICMP header = 1500)
# Eğer bu çalışıyorsa MTU 1500'dür
# Daha küçük dene
ping -M do -s 1400 8.8.8.8
# VPN arkasında test
ping -M do -s 1420 10.0.0.1Bu komutu çalıştırdığınızda ya yanıt alırsınız ya da “Message too long” / “Frag needed” hatası görürsünüz. İkili arama yöntemiyle hangi boyutun çalıştığını bulabilirsiniz. Payload boyutuna 28 eklerseniz (20 IP header + 8 ICMP header) gerçek MTU’yu elde edersiniz.
Windows’ta syntax biraz farklıdır:
# Windows CMD
ping -f -l 1472 8.8.8.8
# -f: Don't Fragment
# -l: payload boyututracepath ile Path MTU Discovery
tracepath komutu, hedefe kadar her hop’taki MTU değerini gösterir. traceroute‘dan daha kullanışlıdır çünkü doğrudan PMTUD testleri yapar.
tracepath 8.8.8.8
tracepath -n google.com
# Çıktıda "pmtu XXXX" şeklinde her hop'ta MTU görürsünüz
# Bir noktada değer düşüyorsa sorunlu hop'u bulmuş olursunuzip komutu ile MTU Kontrolü
# Mevcut arayüzlerin MTU değerlerini göster
ip link show
# Belirli bir arayüz
ip link show eth0
ip link show enp3s0
# Tunnel arayüzleri dahil tümü
ip link show | grep mtu
# Detaylı bilgi
ip -d link show eth0Çıktıda her arayüz için mtu XXXX değerini görürsünüz. VPN ya da tünel arayüzleri için bu değerin düşürülmüş olması gerekir.
tcpdump ile Paket Analizi
Gerçekten ne olduğunu görmek istiyorsanız tcpdump şart. Özellikle ICMP “fragmentation needed” mesajlarını yakalamak için:
# ICMP fragmentation needed mesajlarını yakala
tcpdump -i eth0 'icmp[0]=3 and icmp[1]=4'
# Daha verbose çıktı
tcpdump -v -i eth0 'icmp[0]=3 and icmp[1]=4'
# Belirli bir host ile trafiği izle
tcpdump -i eth0 -v host 192.168.1.100 and icmp
# Büyük paketleri izle (1400 byte üzeri)
tcpdump -i eth0 greater 1400Eğer bu komutla sürekli “fragmentation needed” mesajları görüyorsanız, PMTUD çalışıyor demektir. Hiç görmüyorsanız ama bağlantı sorunu varsa, firewall ICMP’yi bloke ediyor olabilir.
ss ve netstat ile TCP MSS Kontrolü
TCP’nin kendi MTU yönetim mekanizması vardır: MSS (Maximum Segment Size). TCP bağlantı kurulumu sırasında (SYN/SYN-ACK) her iki taraf kendi MSS değerini karşılıklı bildirir. MSS genellikle MTU – 40 (IP header 20 + TCP header 20) olarak hesaplanır.
# Mevcut TCP bağlantılarının MSS değerlerini göster
ss -tin
# Belirli bir porta ait bağlantı
ss -tin dst :443
# netstat alternatifi
netstat -s | grep -i mssGerçek Dünya Senaryoları
Senaryo 1: VPN Üzerinden SSH Çalışıyor Ama SCP Duraksıyor
Bir müşteride tam bu durumla karşılaştım. OpenVPN bağlantısı kuruluyordu, SSH ile login olabiliyorduk, komutlar çalışıyordu ama scp ile dosya kopyalamaya çalışınca ya çok yavaş ilerliyordu ya da hiç başlamıyordu.
Önce VPN arayüzünün MTU değerine baktım:
ip link show tun0
# 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 ...Problem burada. OpenVPN genellikle 1500 yerine 1400-1450 arasında bir değere ihtiyaç duyar çünkü kendi overhead’i var. MTU 1500 olarak ayarlanmış ama VPN tüneli üzerinde paketlere ek header ekleniyor.
Test:
ping -M do -s 1400 -c 3 10.8.0.1 # VPN gateway
# Çalışıyor
ping -M do -s 1450 -c 3 10.8.0.1
# Çalışıyor
ping -M do -s 1452 -c 3 10.8.0.1
# "Message too long (mtu = 1452)"Çözüm olarak VPN arayüzünün MTU’sunu düşürdük:
# Geçici düzeltme
sudo ip link set tun0 mtu 1420
# OpenVPN config'e kalıcı ekleme
# /etc/openvpn/client.conf içine:
# tun-mtu 1420
# mssfix 1380Dosya transferi anında düzeldi.
Senaryo 2: PPPoE Hattında Web Sayfaları Açılmıyor
Bir ofiste DSL bağlantısı üzerinden bazı HTTPS siteleri açılmıyordu. Ping çalışıyordu, curl -v https://example.com bağlantı kuruyordu ama veri gelmiyor, TLS handshake takılıyordu.
PPPoE için kontrol:
ip link show ppp0
# mtu 1492 yazıyor, buraya kadar tamam
# Ama sorun firewall'ın ICMP'yi bloke etmesinden kaynaklanıyor
# iptables kurallarına bakıyoruz
iptables -L -v -n | grep -i icmpSorun PMTUD için gerekli ICMP mesajlarının firewall tarafından drop edilmesiydi. Çözüm olarak iptables’a MSS clamping ekledik:
# MSS clamping kuralı ekle
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN
-j TCPMSS --clamp-mss-to-pmtu
# Ya da sabit değer ver
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN
-j TCPMSS --set-mss 1452
# Kuralı kalıcı yap
iptables-save > /etc/iptables/rules.v4MSS clamping bu tür sorunlar için altın çözümdür. TCP SYN paketlerini yakalayıp MSS değerini zorla düşürür, böylece her iki taraf da büyük paket göndermez ve fragmentasyon ya da drop sorunu yaşanmaz.
Senaryo 3: Kubernetes Cluster’ında Pod İletişim Sorunu
Overlay network kullanan bir Kubernetes cluster’ında pod’lar arası büyük mesaj transferleri takılıyordu. Flannel VXLAN kullanıyordu ve VXLAN 50 byte overhead ekliyor.
# Node'lardaki arayüzleri kontrol et
ip link show flannel.1
# mtu 1450 - iyi ayarlanmış
ip link show cni0
# mtu 1500 - sorun burada!
# cni0 arayüzü MTU'yu flannel.1'den otomatik almıyorDüzeltme:
# Geçici düzeltme
ip link set cni0 mtu 1450
# Kalıcı düzeltme için flannel ConfigMap güncellenmeli
kubectl get configmap -n kube-flannel kube-flannel-cfg -o yaml
# MTU değerini 1450 olarak güncelleBu tür container/kubernetes ortamlarında MTU sorunları çok yaygındır. VXLAN, Geneve, IPsec gibi overlay protokolleri ekstra overhead getirdiği için node MTU’sundan düşük ayarlanmalıdır.
MTU Değerini Kalıcı Olarak Ayarlama
NetworkManager ile
# nmcli ile mevcut bağlantıları listele
nmcli connection show
# Belirli bağlantının MTU'sunu değiştir
nmcli connection modify "Ethernet connection 1" 802-3-ethernet.mtu 1450
# VPN bağlantısı için
nmcli connection modify "MyVPN" ip-tunnel.mtu 1420
# Bağlantıyı yeniden başlat
nmcli connection down "Ethernet connection 1"
nmcli connection up "Ethernet connection 1"systemd-networkd ile
/etc/systemd/network/10-ethernet.network dosyasına:
[Match]
Name=eth0
[Link]
MTUBytes=1450
[Network]
DHCP=yesArdından systemctl restart systemd-networkd.
/etc/network/interfaces ile (Debian/Ubuntu)
# /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
mtu 1450Firewall ve ICMP Politikaları
MTU sorunlarının büyük kısmı ICMP’nin yanlış engellenmesinden kaynaklanır. “Güvenlik” adına tüm ICMP’yi drop etmek yaygın bir hatadır. ICMP Type 3 (Destination Unreachable) ve özellikle Code 4 (Fragmentation Needed) mesajlarının geçmesine izin vermek zorundasınız.
# PMTUD için gerekli ICMP kuralları
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT
# IPv6 için (ICMPv6 Packet Too Big)
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPTIPv6’da fragmentasyon router’lar tarafından yapılmaz, sadece kaynak host tarafından yapılır. Bu yüzden “Packet Too Big” ICMPv6 mesajlarının engellenmesi IPv6 üzerinde çok daha yıkıcı sonuçlar doğurur.
WireGuard için MTU Hesaplama
WireGuard özellikle dikkat ister. WireGuard overhead hesabı:
- IPv4 header: 20 byte
- UDP header: 8 byte
- WireGuard header: 32 byte
- Toplam: 60 byte
Yani dış bağlantının MTU’su 1500 ise WireGuard arayüzü için 1500 – 60 = 1440 byte.
# WireGuard arayüz MTU kontrolü
ip link show wg0
# /etc/wireguard/wg0.conf içinde
[Interface]
MTU = 1420 # Biraz daha konservatif değer, IPv6 için de çalışırEğer WireGuard’ın altındaki bağlantı da bir tünel üzerindeyse (mesela PPPoE üzerinden WireGuard) hesabı tekrar yapmanız gerekir: 1492 – 60 = 1432.
Pratik Kontrol Listesi
MTU sorununu şüphelendiğinizde şu sırayı takip edin:
- Adım 1:
ping -M do -s 1472 hedefçalışıyor mu? Çalışmıyorsa MTU 1500’den küçük demektir. - Adım 2: Binary search ile maksimum çalışan payload boyutunu bulun (1400, 1450, 1460, 1472 deneyin).
- Adım 3:
tracepath hedefile path üzerinde MTU’nun nerede düştüğünü görün. - Adım 4:
tcpdump -i eth0 'icmp[0]=3 and icmp[1]=4'ile PMTUD mesajları geçiyor mu kontrol edin. - Adım 5: Firewall’da ICMP fragmentasyon mesajlarına izin verin ya da MSS clamping ekleyin.
- Adım 6: İlgili arayüzün MTU değerini düşürün ve kalıcı hale getirin.
Sonuç
MTU sorunları, ağ sorunları arasında en çok maskelenen ve en geç teşhis edilen türdendir. “Bağlantı var ama çalışmıyor” şikayetinin arkasında çok sık bu sorun yatar. Temel mantığı kavradığınızda, yani büyük paketlerin geçip geçemediğini test etmeyi öğrendiğinizde, teşhis süreci çok hızlı hale gelir.
Günlük sysadmin pratiğinizde şu üç kuralı benimseyin: Birincisi, her yeni tünel protokolü kurduğunuzda (VPN, overlay network, GRE) ilgili arayüzün MTU değerini manuel kontrol edin ve gerekirse düşürün. İkincisi, firewall kurallarınızda ICMP Type 3 Code 4’ü asla engellemeyin, bu PMTUD’un çalışması için kritiktir. Üçüncüsü, MSS clamping’i özellikle NAT yapan gateway’lerde varsayılan olarak açık tutun. Bu üç alışkanlık, çok sayıda saat süren hata ayıklama seansından sizi kurtaracaktır.