なるほど、正しく通信できなかったのは、
だったのかぁ。
この問題に対してはRoaring Penguin's PPPoE clientの設定ファイル(pppoe.conf)中の項目“MSS”を設定することで回避できた。 良かった良かった。
□以下経緯である。
我が家の対外接続はADSLモデムを通して東京めたりっく通信に繋がっているのだが、ADSLモデムに繋がっているマシンにはEthernet NICが二つ搭載してあって、このマシンにNAT/IPマスカレード機能を持たせて家庭内LANへのサービスを行っている。 いわゆるNAT箱っちゅ〜ヤツですな。
こんな環境でクライアント機からあるWebページを見ようとすると全く応答が無いページがたまに存在することがある。 現象としては以下の感じである。
最初はNAT/IPマスカレードの設定が悪いのかと思っていた。 しかし、いくら設定を変えても事態は改善しない。
とうとうパケットダンプなんてことをして通信の解析をして解ったことは、
ということである。 つまりNATの段階でパケット落ちしているわけではなさそうだ。
なぢぇ！？
□以下カラクリである。
先に答えを書くと、
一時期ICMPを悪用したアタックが急増したので、ICMP DU/FN(Destination Unreachable/Fragmentation Needed)を落したい気持ちは解るんだけど、実はコレ、ひどい話なんです。
TCP/IPには“Path MTU Discovery”(RFC1191)という技術があって、これを使って通信相手のMTUを事前に調べることがある。
ことなどが原因でスループット低下を引き起こすからである。 だから、予め相手のMTUを取得して、そのMTUサイズでパケットを送ってやれば余計な処理や喪失の可能性も減ってスループット向上につながると、まぁこんな狙いがある。
まんまと相手のMTUが解ったので、極力無駄を避けるために、
ことになるんだけど、ここでNAT箱を介した上の図式のMTUをおさらいしてみると…
そうなんです、終端のEthernetよりも途中のADSLの方がMTUが小さい(1492 < 1500)
んです。 PPP over Ethernetっちゅ〜くらいで、Ethernetフレーム上にカプセル化するので当たり前といえば当たり前なんだけど、この差が諸悪の根源の一つ。
つまり、
のである。 しかし、ここで、
フラグメント不可が指定されているので、このメッセージで先方にフラグメントを許可してもらうようにお願いする。 フラグメントが許可されていれば、例え1500バイトの大きさのパケットが来ようが、ここで少なくとも二つのパケットに分割してやれば1492バイト上に通すことができるという寸法。 ところが、このICMPメッセージをルータやホストの設定等で受け付けないようにしているのが諸悪の根源の二つ目。
結局、
ので、手前には一向にデータが届かない、とまぁこんなカラクリがある。
ちなみに、インターネットでは経路上に異なるMTUのネットワークが存在しても良いことになっている。 したがって、ICMP DU/FNメッセージを受け付けないという設定はかなり反則な行為である。
この問題のラフな解決法はPath MTU Discovery時にウソのMTUを渡す、これが最初に書いたMSSを設定することなのです。