FreeBSD: portsnap コマンドがタイムアウトする

前メモで確認したportsnapによる ports 管理を、他のFreeBSDサーバーにも適用させたいと思います。

私が管理中のFreeBSDサーバーは複数台あるので、それぞれにおいて cvs から portsnap に移行させようと作業を開始したところ、最初の2台は /usr/ports 以下のファイルを更新出来たものの、一台は portsnap サーバーとの通信がタイムアウトしてしまうようで、ports を更新出来ないという問題が発生しました。

# /usr/sbin/portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... none found.
Fetching snapshot tag from portsnap.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Jan 15 09:05:00 JST 2013:
801dfc7ad1cf139e057910a544e1d6f6934992bd0583 0% of 67 MB 0 Bps
fetch: transfer timed out
fetch: 801dfc7ad1cf139e057910a544e1d6f6934992bd05837acc44b3d64a495669.tgz appears to be truncated: 0/71136319 bytes

なぜ？

よく見てみると、portsnap fetch を成功するマシンだと、

Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching public key from ec2-ap-northeast-1.portsnap.freebsd.org... done.
Fetching snapshot tag from ec2-ap-northeast-1.portsnap.freebsd.org... done.

となり、ミラーサーバーを複数発見しているが、タイムアウトするマシンだと、

Looking up portsnap.FreeBSD.org mirrors... none found.
Fetching snapshot tag from portsnap.FreeBSD.org... done.

となって、ミラーサーバーを発見出来ないようです。DNSに何か問題があるのか？と考えて、DNSサーバーをgoogle様の8.8.8.8に変更してみたところ、

Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-ap-northeast-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Jan 15 09:05:00 JST 2013:
801dfc7ad1cf139e057910a544e1d6f6934992bd0583 0% of 67 MB 0 Bps
fetch: transfer timed out

とミラーサーバーを発見出来るようになったものの、コマンドの結果はタイムアウトで終了。
症状から推測するに、上位のゲートウェイがパケットを拒否している時の症状に似ている気がします。具体的には、PPPoEのMTU,MRU サイズが経路ネットワークパラメーターと一致していない場合や、パケットフィルタリングでパケットがドロップしている時の症状に似ています。しかし使っているポートは80なので、HTTPがブロックされているとは思えません。幸い、問題のFreeBSDサーバー設置場所にはもう一つ別のプライベートネットとゲートウェイがあり、（面倒ではありますが）スタティックルーティングテーブルを追加すればゲートウェイが原因かどうかの切り分けは出来そうです。

試しに、portsnap.freebsd.org への通信はプライベートアドレス側の別のゲートウェイ(MTU 1500)を使って通信するように設定を変更し、portsnap コマンドを発行してみることにしたら、

# portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-ap-northeast-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Jan 15 09:05:00 JST 2013:
801dfc7ad1cf139e057910a544e1d6f6934992bd0583100% of 67 MB 574 kBps 00m00s
Extracting snapshot... done.

ということで、あっさりportsnapサーバーへの通信が通ってしまいました。

原因はプロバイダーのゲートウェイがパケットをブロックしているか、（portsnapサーバーがフラグメント禁止指定で送っている場合）MTU,MRU が大きすぎると判明しました。いずれも portsnapコマンドの直接責任ではなく、通信経路が原因のようです。
このメモを書いている現時点では、portsnap の extract 中なので試せませんが、次のような回避策が考えられます。

1. HTTP_PROXY を使ってみる
2. MTU,MRUを小さくしてみる
3. 問題なく動作するマシンにVPNトンネルを掘って、portsnapだけVPN経由にする

と、複数の回避策をリストアップしましたが、そもそも、デフォルトゲートウェイの適切なMTUはいくらなんだろう？根本的なパラメーターを確認していなかったことに気づきました。
ping を使ってMTUを調べられるので、手元サーバーと問題のリモートサーバーを使って、MTUを計測してみることにしました。

# ping -D -g 1350 -G 1430 www.example.net

-Dはパケット分割禁止、-g と -G で計測するパケットサイズの最低値と最大値を指定。
そうすると、ping が戻ってこなくなるサイズがMTUで、実際、以下のメッセージが表示されて、MTUがフレッツのデフォルトサイズ 1454 よりもかなり小さい、1396 だと判明しました。

36 bytes from www.example.net (123.124.125.126): frag needed and DF set (MTU 1396)

確認作業を行ってメモを残している間に portsnap の extract が終了したので、PPPoE のMTU, MRU値を1396に修正してOSのリブートを行いました。さらに /var/db/portsnap を初期化して、portsnap fetch を掛けてみると、あっさり以下のように転送が始まりました。

# portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... none found.
Fetching public key from portsnap.FreeBSD.org... done.
Fetching snapshot tag from portsnap.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Jan 15 09:05:00 JST 2013:
801dfc7ad1cf139e057910a544e1d6f6934992bd0583 11% of 67 MB 462 kBps 02m17

原因は、上位ゲートウェイのMTUだったようです。

portsnap でタイムアウトエラーが出たら、まずは経路のMTUを確認し、自サーバーのMTU/MRUがそれ以下になっているかどうかを確認するのが良さそうです。