MSS ルールはルーターでは効くが Squid には届かない

管理者は FORWARD に TCPMSS クランプを追加しました。直接ルーティングされる通信は改善しますが、ローカルの Squid インスタンス経由のダウンロードは依然として止まります。プロキシのウェブサイト接続は、クライアントの TCP 接続がそのまま連鎖を通るものではありません。

通常の終端型フォワードプロキシでは、クライアント側の接続はローカルで終わります。プロキシは オリジンまたは親プロキシへの二本目の TCP 接続 を張ります。Linux ではその接続のために生成されるパケットはローカルの出力経路を通ります。

したがって FORWARD 専用のルールは完全に機能していても、調整すべきハンドシェイクを取り逃がします。フックを選ぶ前に実際の接続と SYN の向きを図にしてください。コンテナや別の名前空間はさらにルーティング区間を増やすので、正しい位置はプロセスがどこで動くかで変わります。

PMTU の数値をそのまま MSS に入れない

経路 MTU は IP パケットのサイズです。TCP MSS は TCP ペイロードを表し、関係するヘッダーを考慮する必要があります。同様に ping のペイロード長は IP パケット全体の長さではありません。よく知られた 28 バイトの加算は基本的な IPv4 ICMP echo の構成に対応するもので、あらゆるアドレスファミリーやカプセル化に当てはまるわけではありません。

TCPMSS ターゲットは明示的な値と PMTU クランプを記録しています。クランプは依然として経路の MTU 情報に依存しており、経路探索が健全であることの証明でも、必要な ICMP メッセージを許可することの代わりでもありません。

症状を理論と照らし合わせます。ハンドシェイクが完了した後に大きな転送で止まるなら、パケットサイズを調べる根拠になります。応答のない SYN の繰り返しや即時の reset はより広い説明を要します。小さなパケットの失敗は過大なデータセグメントを証明しません。

動作する直接接続と失敗するプロキシ接続は、記録上はっきり分けておきます。同じマシンからでも、送信元、経路、カプセル化が異なることがあります。