MTU blackhole 問題 の続き
一時期 代替機として NetBSD2.0RC5 を使ってましたが、こいつだと何故か ipnat を有効にすると TCPのセッションが切られてしまうという問題があり、だましだまし使いつつ、以前のNetBSD1.6.2 をいれたマシンに戻した訳です。
ちゃんと動いているから安心してたら、知己からうちで預かってる Web サイトのページが見れないと悲鳴が上がりまして。
で、調査がこれ。DMZ 側のインターフェイス ex0 で tcpdump で採取しました。
20:16:46.353879 xxx.xxx.xxx.xx.35252 > sepia.front.nest.or.jp.www: S 4062547751:4062547751(0) win 5840 <mss 1460,sackOK,timestamp 2403195649 0,nop,wscale 0> (DF)
20:16:46.354995 sepia.front.nest.or.jp.www > xxx.xxx.xxx.xx.35252: S 2616774323:2616774323(0) ack 4062547752 win 24616 <nop,nop,timestamp 114090451 2403195649,nop,wscale 0,nop,nop,sackOK,mss 1460>
問題は一つめのパケット。こいつは pppoe0 から入ってきて DMZ 側の ex0 から出力される訳ですが、mss が 1460 のままである。
戻りも 1460 になってるけど、これは pppoe0 を通る時点で mssclamp されて ipnat.conf で指定した mss である事の 1360 にされます。
そして、ちと設定ミスでこの sepia というマシン (Solaris8 で動いてます)は MTU Path Discovery が off になってました。
このため、sepia -> xxx.xxx.xxx.xx の経路で MTU1460 のパケットが飛び、NetBSD1.6.2 なルータが悲鳴を上げて(ICMPで MTU サイズの変更をお願いして)、通常ならそれを受けて MTU を 1360 に落とすところが MTU Path Discovery が off になっているせいかこれを受け取らず、そして blackhole が発生したという訳です。
( なお、この悲鳴を上げて mss を下げる効果が sysctl でせっていする mss_ifmtu で発生すると、いう事みたいです。 )
とりあえず対処したのですが、問題は 「MTU path blackhole?(4)」で述べたパッチを当てたカーネルであるということです。このため、pppoe0 から出て行くパケットだけではなく、入ってくるSYNパケットの mss も mssclamp するはずなのですが、してくれておりません。
ここまでが昨日の夜の話。
今日、さっきの昼休みに追試をしたところ
「DMZ のマシン -> お外のマシン 」という通信の場合、pppoe0 を通って出て行く場合、それから相手から帰ってきて pppoe0 から入ってくる場合双方とも mssclamp がかかって mss が1360 になってました。これは (4) の結果と合致します。
しかし、「お外のマシン -> DMZ のマシン」という通信の場合は、外から pppoe0 を通って入っていくときに mssclamp がなされません。これは上の問題と合致します。
つまり、私が直したコードは不完全で、内部から外部への通信の場合にしか clamp がされてないみたいです。
じゃあ外部から発信された場合も直せばいいじゃん、と思ったのですが...、うう、ip_nat.c のソース見たってわっかんねーよ(涙)
素養がない状態でのコード追っかけには限度があるみたいです Orz...。
なお、通常の map に加えて
map ex0 0.0.0.0/0 -> 0/0 mssclamp 1360
という設定を追加すれば「ex0 を通るときに mssclamp がかかって SYNパケット内の mss が1360 に書き換えられる」のですが...美しくねぇので却下気味(--;;;
(なお、bimap は mssclamp オプションを受け付けない模様)
なので、あと考えられるのは、1.6.2 標準の ipfilter (2.4.29 ベース)を使うのではなく3.4.35 ないしは 4.1.3 にそこだけアップデートするというのが一つ、もう一つは NetBSD2.0 (release)を試してみる、って事ですか。
何が嫌って、試すたびにサービス落とす羽目になること、かな。
