以下の構成のネットワークがある。ネットワークの利用者から,「FTPサーバーへのファイル転送がどうも遅い。1Kバイトのファイルであっても10秒ほど時間がかかる」というトラブル申告があった。原因がわからないため,小さいサイズのファイルを実際に転送した際のパケットをキャプチャしたところ,以下のような結果となった。この結果から,トラブルの解決策として最も適切だと思われるものを以下の選択肢から一つ選びなさい。

パケット・キャプチャでトラブル原因を推測する
※以下をクリックすると拡大画像がポップアップします
パケット・キャプチャでトラブル原因を推測する(キャプチャ画面)

[選択肢]
a. FTPサーバーで,DNSの設定を変更する
b. DNSサーバーで,FTPサーバーの逆引き設定レコードを作成する
c. ルーターでファイアウォール(フィルタリング)の設定を変更する
d. 192.168.135.0/24のネットワークで,有効帯域を拡大する
e. LINUX1マシンでFTPのモード(アクティブ/パッシブ)を変更する

[解説]
 問20の正解は,選択肢cの「ルーターでファイアウォール(フィルタリング)の設定を変更する」です。

 この問題は,TCP通信やファイアウォールに関連したトラブル解決の実践問題です。通信に時間がかかっているというトラブルなので,パケット・キャプチャの経過時間の欄に着目して解析をしてみましょう。

 キャプチャしたパケットを見ると,フレーム8~10の間で約9秒の時間がかかっていることがわかります。この間の通信を確認すると,FTPSRV(192.168.171.129)からLINUX1(192.168.135.71)のポート113に対して3回通信を行っています。「SYN」という表示から,これはTCP通信を開始するときのSYNパケットであることが確認できます。

 パケット・キャプチャの中で,同様にSYNパケットが送信されている箇所は他にフレーム1と31にあります。フレーム1ではポート21(FTPのポート)に対するSYNパケットが送信されており,およそ0.001秒後にフレーム2としてSYN-ACKパケットが返信されています。フレーム31のSYNに対しても即座にフレーム32としてSYN-ACKパケットが返信されています。一方,フレーム8~10のSYNパケットに対する返信はありません。

 フレーム11は,FTPSRVがLINUX1に対して返信したプロンプト表示のデータです。これ以降,フレーム1~3で確立されたコネクション(制御用コネクション)を使ったやりとりが続きます。フレーム34のデータ転送要求に対するレスポンスがフレーム39で,これでデータ転送の準備が整いました。最後のフレーム40で,フレーム31~33で確立されたコネクション(データ通信用コネクション)を使って通信しています。

 それでは,選択肢を吟味していきましょう。

 選択肢aについて,フレーム4~7および35~38で,FTPSRVとDNSサーバーとの間の通信が発生しており,192.168.135.71(LINUX1)の逆引きの問い合わせ(71.135.168.192.in-addr.arpa.に対する問い合わせ)が行われています。これについてはほぼ即座にDNSサーバーから返答が行われていますので,今回の遅延の原因ではないと考えられます。

 選択肢bについて,パケット・キャプチャ中では,FTPサーバー(192.168.171.129)に対する逆引きの問い合わせは行われていませんので,レコードを作成しても事象は改善しないと考えられます。

 選択肢dについて,SYNパケット自体は「Len=0」という表示にもあるように,ペイロード(データ格納部)を持たない小さなパケットです。そのため,帯域を拡大しても,SYNパケットの遅延は解消しないと考えられます。

 選択肢eについて,今回はフレーム30の「Passive Mode」という記載から,パッシブ・モードで通信が行われていることが確認できます。しかし,遅延はこれ以前の箇所で発生していますので,この設定を変更しても遅延は解消しないと考えられます(下図)。

やりとり全体の流れ

 それでは,なぜファイアウォール(フィルタリング)の設定を変更することで,今回の事象が解決できるのでしょうか。今回LINUX1のTCPポート113番に対するSYNパケットが送出されています。もしLINUX1においてポート113で待機しているプロセス(サービス)が存在しない場合は,以下のように即座にリセット(RST)パケットが返され,今回のように3回もSYNパケットが繰り返し送られることはありません(下図の上側)。

さまざまなケース

 以上のように,113番ポートに対する通信が,どこかでフィルタされていることが今回のトラブルの原因として考えられます。従って,ルーターのフィルタに関する設定を変更することが,トラブルの解決策になるわけです。なお,実際の環境では,ルーター以外にもLINUX1やFTPSRVといったサーバー自体でパケットがフィルタされている可能性もあります。ルーターの設定に問題が見られなかった場合は,例えば192.168.135.0/24のネットワークでもパケットをキャプチャして,ルーターの先までSYNパケットが到達しているかどうかを調べてみるのがよいでしょう。

 では,どのように設定を変更するのがよいのでしょうか。ルーターで113番ポートを通過させる設定に変更しても構いませんが,それでは万一LINUX1の113番ポート上で不正なサービスが起動された場合,その通信も許可してしまうことになります。

 一般的なファイアウォール(ルーター)では,こうした場合を想定して,パケットをフィルタする際に,単に破棄する(DROP)モードの他に,パケットを拒否する(REJECT)モードを備えています。拒否するモードにした場合,以下のようにICMPでエラーが返答されるので,応答を待って時間が経過してしまう事象は回避されます(上図の下側)。

 「破棄」と「拒否」を意味する具体的な用語は,ルーターやファイアウォールのベンダーによって若干差がありますので,使っている機器のマニュアルを確認してください。

 なお,113番ポートはIDENTと呼ばれるサービスが使うポートです。IDENTとは,送信者がどのようなユーザーなのかを確認する古いプロトコルで,古いサーバー・プログラムなどで有効になっていることがよくあります。ただし,なりすましに対する対策がないため,最近ではあまり使われていません。しかし,使わないからといって単にパケットをで「破棄」する設定にしておくと,この問題で取り上げたようなトラブルが発生することがあるわけです。