リセットパケットを投げたのは誰だ?

他ベンダーとのネットワーク接続作業でよくあるのですが、ネットワーク接続したはいいけれど通信が上手く通らない、なんて場合があります。PINGは通るのに対向先のサーバーなどネットワーク機器にTCPコネクションが張れない、そんな経験をしたことはありませんか?

通信元から通信先まで調査する権限があれば良いのですが、他ベンダーと絡むと相手側のネットワークを調べるわけにもいかず、大抵は力関係の弱いベンダー側のせいにされて自社のネットワークを調査する羽目になります。他ベンダーが管理するネットワーク範囲については、当然のことながら相手側の物理構成図も論理構成図も手元にありません。そんなときの対処方法の参考になれば幸いです。

スポンサーリンク
スポンサーリンク

パケットキャプチャをして原因を探る

シチュエーションとして、サーバーへPINGは通るけれどSSHログインが切断されてしまう、という状況を想定します。この場合、サーバーのポート22番が閉じている、サーバーのFW機能で弾いている、経路上のFWで弾いている、といった状況が考えられます。

さてさて、SSHログインが切断されると言う事で、まずはパケットキャプチャをしてみます。すると、サーバーのIPアドレスからリセットパケットが送信されている事が判りました。PINGは問題なく通ります。では問題。このとき誰がリセットパケットを送ったのでしょうか?次のパケットキャプチャの結果から考えてみてください。

さて、つぎのうち答えはどれでしょう??

  1. サーバーがリセットパケットを送信した
  2. 経路上にあるネットワーク機器(もしかしてFW)がリセットパケットを送信した

答えは次の章で。IPヘッダーの値に注目してください。答えはでましたか?

IPヘッダーはウソをつかない

どうですか?だれがリセットパケットを送信したのかすぐにわかりましたか?確信を持って即答できなければ、このまま読み進めてください。

正解は2番。「経路上にあるネットワーク機器(もしかしてFW)がリセットパケットを送信した」です。

このような状況で注目するべきはIPヘッダーの「TTL」の値です。TTLはIPヘッダーに含まれる8ビットの値です。この値はネットワーク機器を経由するごとにひとつずつ値が減ります。Tracerouteはこの仕組みを利用して通信経路を調べていますね。TTLの特徴のひとつに、OSのTCP/IP実装ごとにデフォルト値が異なる、というものがあります。

まずキャプチャ結果2行目のTTL値に注目してください。TTL値は63ですね。これはSSHログインが切断されたときのものです。次に8行目に注目してください。このときのTTL値は61です。これはICMP応答を受信したときのものです。おかしくありませんか?送信元IPアドレスは同じなのにどうしてTTL値が違うのでしょう?

その答えをつぎのフロー図で説明します。

TCPリセット送信フローこのフロー図はPINGを実行したときと、SSHが切断されたときの通信の流れとTTL値を示しています。PINGを実行したとき、パケットはFWを通過してサーバーがPING応答を送信しました。このとき、サーバーが設定したTTL値は64です。その後、ルーターとFWを経由してPING応答が到着するとTTL値は61まで減算されました。パケットキャプチャの結果と一致しますね。

これに対してSSHが切断されたときはどうでしょうか?まずFWのポリシーに引っかかってFWで止められます。そしてFWはリセットパケットを送信します。偶然にもサーバーと同じくFWのデフォルトTTL値は64でしたので、ルーターを経由してリセットパケットが送信元へ到達したときTTL値は63に減算されました。

さきほど申し上げましたが、TTLのデフォルト値はOSのTCP/IP実装に依存します。通常、カーネルパラメータをいじらない限りTTLのデフォルト値は「64」「128」「255」のどれかです。ですので、返って来たTTL値をみれば送信元のデオフォルトTTL値は簡単に推測できます。デフォルト値はわかっているので、ホップ数もおのずと判ります。今回の例でいえばリセットパケットを投げたネットワーク機器(FW)の間にひとつネットワーク機器がある事がわかりますよね?

最後に

顧客に「おたくのネットワーク設定ミスじゃないの?」なんて言われたら「2ホップ先にFWがありませんか?そこで弾かれている可能性があります。FWがあるならばポリシーチェックを依頼して頂けますか?」なんて即答できたら良いですね。

また、よくある状況としてセッションタイムアウトによる切断にも使えます。サーバー、ロードバランサー、FWのいずれかがセッションタイムアウトしてリセットパケットを投げてしまい、どこで切断しているんだ?なんて調査が入る事があります。そういった場合、それぞれのタイムアウト設定を見直す場合がありますが、そういった状況でもTTLの値からどの機器がリセットパケットを投げたのか目星を付ける助けになるのではないか、と思います。

スポンサーリンク
スポンサーリンク
スポンサーリンク

フォローする

コメント

  1. […] 以前投稿した「リセットパケットを投げたのは誰だ?」はリセットパケットに主眼を置いているため、うまく活用できない人もいるのではないか?と思っていた矢先、ネットワーク構築 […]