MSS kuralı yönlendiricide çalışır ama Squid'i atlar
Her paketin FORWARD'dan geçtiğini varsaymak yerine MTU mantığını proxy'nin açtığı ayrı TCP bağlantılarına uygulayın.
Bir yönetici FORWARD'a TCPMSS sıkıştırması ekler. Doğrudan yönlendirilen trafik iyileşir, ancak yerel Squid örneği üzerinden indirmeler hâlâ takılır. Proxy'nin web sitesine bağlantısı, istemcinin TCP bağlantısının o zincirden geçmesi değildir.
Sıradan bir sonlandıran forward proxy'de istemci tarafındaki bağlantı yerelde biter. Proxy kaynağa veya üst vekile doğru ikinci bir TCP bağlantısı açar. Linux'ta o bağlantı için üretilen paketler yerel çıkış yolunu izler.
Bu nedenle yalnızca FORWARD için yazılmış bir kural tamamen çalışır durumda olup yine de ayarlamayı amaçladığı el sıkışmayı kaçırabilir. Bir kanca seçmeden önce gerçek bağlantıyı ve SYN'in yönünü haritalayın. Konteynerler veya ayrı ad alanları bir yönlendirilmiş kesit daha ekleyebilir, bu yüzden doğru yerleşim sürecin nerede çalıştığına bağlıdır.
PMTU sayısını doğrudan MSS'ye koymayın
Yol MTU'su bir IP paket boyutudur. TCP MSS, TCP yükünü tanımlar ve ilgili başlıkları hesaba katmalıdır. Aynı şekilde ping yük uzunluğu tam IP paket uzunluğu değildir. Bilinen 28 baytlık ekleme temel IPv4 ICMP echo düzenine bağlıdır, her adres ailesine veya kapsüllemeye değil.
TCPMSS hedefi açık değerleri ve PMTU sıkıştırmasını belgeler. Sıkıştırma hâlâ rotanın MTU bilgisine dayanır; yol keşfinin sağlıklı olduğunun kanıtı değildir ve gerekli ICMP iletilerine izin vermenin yerini tutmaz.
Belirtiyi kuramla da eşleştirin. Tamamlanan el sıkışmanın ardından büyük aktarımlarda takılma, paket boyutunu araştırmayı haklı çıkarabilir. Yinelenen yanıtsız SYN'ler veya anında reset daha geniş bir açıklama gerektirir; küçük paketlerin başarısız olması aşırı büyük bir veri kesiti kanıtlamaz.
Kayıtta çalışan doğrudan bağlantı ile başarısız proxy bağlantısını ayrı tutun. Aynı makineden bile farklı kaynaklar, rotalar ve kapsülleme kullanabilirler.