GRE tüneli ve MTU: "site açılıyor ama dosya inmiyor" sorunu
Yazan: Datafex Teknik EkibiYayın: 4 dk okuma
Temizlenmiş trafiği filtreleme katmanından alıp kendi altyapınıza taşımanın iki yolu var. Sunucularınız koruma sağlayıcısının tarafındaysa doğrudan bağlantı; başka bir lokasyondaysanız GRE tüneli. İkinci yol çalışır ve yaygındır — ama beraberinde, kurulumda beş dakika sürecekken sonradan günlerce aranan bir ayrıntı getirir.
Belirtisi hep aynı cümleyle tarif edilir: site açılıyor ama dosya inmiyor. Sebebi de hep aynıdır: paket boyutu.
GRE her pakete başlık ekliyor
GRE bir kapsülleme protokolüdür. Sizin paketinizi olduğu gibi alır, üzerine kendi başlığını koyar ve tünelin diğer ucuna gönderir. Bu başlık paket başına 24 bayt yer kaplar.
Sonuç aritmetiktir. Standart 1500 baytlık MTU üzerinde çalışan bir tünelde, içeride taşıyabileceğiniz yük 1476 bayta iner. Tünelin uçlarında MTU'yu bu gerçeğe göre ayarlamazsanız, işletim sistemi hâlâ 1500 baytlık paketler üretmeye devam eder — ve o paketler tünelden geçemez.
Belirti neden bu kadar tuhaf
Küçük paketler sığar, büyük paketler sığmaz. Gündelik trafiğin büyük kısmı küçük paketlerden oluşur: DNS sorgusu, TLS el sıkışması, bir HTTP isteğinin kendisi, bir oyun istemcisinin durum sorgusu. Bunlar sorunsuz geçer. Site açılır, giriş yaparsınız, panel çalışır.
Sorun, gerçekten veri taşıyan büyük paketler devreye girdiğinde başlar: dosya indirme, yedek aktarımı, büyük bir form gönderimi, veritabanı dökümü. Bunlar tam boyutlu paketler üretir ve tünelde sessizce kaybolur.
"Sessizce" kelimesi burada önemli. Yol MTU keşfi (Path MTU Discovery) dediğimiz mekanizma, gönderenin "bu paket sığmadı, küçült" bilgisini geri alması esasına dayanır. Bu bilgiyi taşıyan ICMP mesajları yol üzerindeki bir güvenlik duvarı tarafından düşürülüyorsa — ki "ICMP'yi tamamen kapatalım" kararı çok yaygındır — gönderen hiçbir şey öğrenmez. Aynı büyük paketi tekrar tekrar gönderir, her seferinde kaybolur, bağlantı hata vermeden asılı kalır. Hata mesajı olmadığı için de önce uygulamada, sonra diskte, sonra veritabanında aranır. Cevap ise ağdadır.
İki ayar: tünel MTU'su ve MSS clamping
Çözüm iki parçalıdır ve ikisi de tünel kurulurken yapılır.
Birincisi tünel arayüzünün MTU'su. Tünelin iki ucunda da, kapsülleme başlığı düşülmüş değere ayarlanır. Doğru sayı, altta yatan yolun gerçek MTU'suna bağlıdır — her yol 1500 değildir — bu yüzden değeri varsayımla değil, operatörünüzle teyit ederek girin.
İkincisi TCP oturumları için MSS clamping. TCP el sıkışması sırasında iki taraf, kabul edebilecekleri en büyük segment boyutunu (MSS) birbirine bildirir. Clamping, tünelden geçen bu bildirimi tünele sığacak bir değere indirir. Böylece oturum daha en başında doğru boyutta kurulur ve PMTUD'nin çalışıp çalışmadığı önemsiz hale gelir. Buradaki değer de tünel MTU'sundan türetilir; IP ve TCP başlıkları düşüldükten sonra kalan miktardır ve IPv4/IPv6 farkına göre değişir.
MTU'yu ayarlayıp clamping'i atlamak en sık görülen yarım çözümdür. Kendi sunucunuz doğru boyutta paket üretmeye başlar ama karşı taraftaki istemci bunu bilmez; indirme yönündeki trafik hâlâ kaybolur.
MSS clamping neyi çözmez
MSS bir TCP seçeneğidir. UDP'de karşılığı yoktur — yani clamping, UDP trafiğine hiçbir şey yapmaz. Oyun, ses ve bazı tünel protokolleri UDP üzerinde çalışır ve paket boyutuna uygulamanın kendisi karar verir.
Pratikte UDP tabanlı oyun trafiği çoğunlukla küçük paketler kullandığı için sorun çıkarmaz; ama büyük durum güncellemeleri ya da harita/kaynak aktarımı yapan protokoller istisna olabilir. Bu yüzden tünel devreye alındığında testi yalnızca web arayüzüyle yapmayın: gerçek oyun istemcisiyle, gerçek dosya transferiyle ve mümkünse parçalanmasına izin verilmeyen büyük paketlerle deneyin. ping komutunun "parçalama" ve "paket boyutu" seçenekleri bunun için vardır; seçenek adları işletim sistemine göre değişir.
Belirti gerçekten MTU mu?
Teşhisi hızlandıran ayrım şudur: MTU sorunu bağlantıyı kurar, taşımayı bitiremez.
| Gördüğünüz | MTU sorununa uyar mı |
|---|---|
| Küçük istekler çalışıyor, büyük transferler ortada asılı kalıyor | Evet — tipik örnek |
| Bağlantı hiç kurulmuyor, hemen hata dönüyor | Hayır — yönlendirme ya da güvenlik duvarı |
| Her şey yavaş ama sonunda tamamlanıyor | Hayır — bant genişliği ya da gecikme |
| Aynı dosya bazen iniyor bazen inmiyor | Kısmen — yol değişiyor olabilir, iki yolun MTU'su farklıysa |
| Belirti yalnızca tünelden geçen trafikte var | Evet — kuvvetli işaret |
Son satır en ayırt edicisidir. Aynı sunucuya tünel dışından erişebiliyor ve büyük transfer sorunsuz tamamlanıyorsa, sorunu tünelde aramak neredeyse kesin doğru adımdır.
Tünel yerine doğrudan bağlantı
Bütün bu sınıfın ortadan kalktığı bir seçenek var: sunucular filtreleme katmanıyla aynı ağdaysa kapsülleme gerekmez. Donanımınız sizde kalsın istiyorsanız co-location, kendi rafınızı ve kendi switch'inizi kurmak istiyorsanız kabin kiralama bu düzeni verir. Trafiğin bir parçası burada, bir parçası uzak lokasyonda olan karma kurulumlarda ise tünel kaçınılmazdır ve MTU konuşması baştan yapılır.
Hangi yolun seçileceği koruma modelini değiştirmez: BGP koruma her iki durumda da bloğunuzu Datafex ağı üzerinden duyurur, hacimsel saldırıları router seviyesinde keser ve geri kalanı Fexwall filtresinden geçirir. Değişen tek şey temiz trafiğin size hangi yoldan ulaştığıdır.
Kurulumdan önce netleşmesi gereken beş şey
- Tünelin iki ucundaki IP adresleri ve altta yatan yolun gerçek MTU'su.
- Tünel arayüzünün her iki uçtaki MTU değeri — tek uçta ayarlamak yeterli değildir.
- TCP için MSS clamping'in hangi tarafta uygulanacağı.
- Yol üzerinde ICMP'nin filtrelenip filtrelenmediği; filtreleniyorsa PMTUD'ye güvenilemeyeceği.
- Kabul testinin nasıl yapılacağı: küçük istek değil, büyük transfer.
Bu beş maddeyi kurulum gününden önce yazılı hale getirmek, "site açılıyor ama dosya inmiyor" belirtisini sonradan aramaktan çok daha ucuza gelir. Mevcut kurulumunuzda bu belirtiyi şimdiden görüyorsanız, tünel uçlarının MTU değerleriyle birlikte bize yazın — teşhis genellikle ilk bakışta çıkar.