①事象

1つのURLに対して2つのIPアドレスをDNSサーバに登録し、httpsでURLに対して
アクセスすると、一部のフレームがタイムアウトする。

②構成
構成図
PC---モデム----LB---Webサーバ1
      Webサーバ2
      Webサーバ3
      Webサーバ4

PCのOS:Windows7、IE8.0
URL:www.test.jp
IPアドレス:1.1.1.1、2.2.2.2
     ※1.1.1.1はLBのVIP①、2.2.2.2はLBのVIP②
LB:VIP①、②にWebサーバ1~4を組み込み。
  Webサーバ1~4に対してラウンドロビンで振り分け。
Webサーバ:各サーバは単体で通信を処理。セッション動機は実施していない。

③質問事項
1.PCでhttpsの通信をキャプチャーすると、1回のアクセスでVIP①に行ったり
 VIP②へ行ったりしております。
 例えばVIP①のIPアドレスでhttpsの認証が完了した後に実施する5分間程度の通信内
 で突然VIP②のIPアドレスを使用して通信することがありえるのでしょうか。
 もしあるならトリガーをご教授頂きたく存じます。
以上よろしくお願い致します。

回答の条件
  • URL必須
  • 1人5回まで
  • 登録:
  • 終了:2011/09/21 10:13:30

ベストアンサー

id:JULY No.1

回答回数966ベストアンサー獲得回数247

1.PCでhttpsの通信をキャプチャーすると、1回のアクセスでVIP①に行ったり

 VIP②へ行ったりしております。

 例えばVIP①のIPアドレスでhttpsの認証が完了した後に実施する5分間程度の通信内

 で突然VIP②のIPアドレスを使用して通信することがありえるのでしょうか。

普通に考えると、ちょっとあり得ません。


というのは、最近のアプリケーションの場合、名前解決の結果からどの IP アドレスを選択するかは、アプリケーション側の問題になるからです。


実際のアプリケーション側の作りとして、名前解決の部分は、古くは gethostbyname() というインタフェースが使われていましたが、この gethostbyname() では IPv6 に対応できないため、getaddrinfo() というインタフェースを使うようになってきています。


この getaddrinfo() の場合、IPv4、IPv6 を含めて、候補となる IP アドレスのリストが返ってきます。対応するアドレスが1つしか返ってこない gethostbyname() との大きな違いになります。


で、このリストの順序が RFC 3484 に従ってソートされるので、以前のような DNS によるラウンドロビンが有効ではない、という話があります。以前であれば、アプリケーション側は gethostbyname() の結果を使っていれば、結果的にラウンドロビンされていたのが、IPv6 に対応しようとすると、アプリケーションが対応しない限り、RFC 3484 の結果の順序で先になるアドレスが優先されることになります。この辺の話は、手前味噌ですが、以前にちょっと調べて書いたことがあります。

DNS でラウンドロビンは当てにならない。 - JULYの日記


ということで、途中で IP アドレスが変わるのは、OS 側の問題ではなく、意図的にアプリケーション側が変更しないと変わらないと考えられます。


パケットキャプチャをしているという事なので、その結果に関してちょっと確認してもらいたいのですが、IP アドレスが変わる時は、新たなコネクションが始まっている、つまり、TCP の 3 way handshake が開始されてますか? もし、3 way handshake が無く、TCP の通信として「途中」のパケットが送らているとしたら、かなり異常な現象で、私には理解できない現象になります。もちろん、そのパケットキャプチャは、すでにコネクションが張られていない、クリーンな状態から始めていることが前提です。


もし、新たな TCP 接続が別の IP アドレスとして始まっている場合、実は HTTP の中身で、直接 IP アドレスが書かれている URL が指定されていたりしてませんでしょうか? SSL/TLS 化した場合、普通にキャプチャすると中身が分かりませんが、wireshark の場合、サーバ側の秘密鍵を読み込ませて、中身を見る事ができます。


CTX116872 - WiresharkでSSL/TLSトラフィックを解読する方法 - Citrix Knowledge Center


もし、IP アドレスが変わるタイミングがいつも同じなら、この可能性が高いと思います。


もし、新たな TCP のコネクションが発生している訳でもなく、かつ、PC 側のポート番号が同じだとしたら... かなり謎です。PC 側のポート番号が違っていれば、3 way handshake を見逃しているか、キャプチャを始めた時点ではすでにコネクションが成立していた可能性が高いのですが...。


余談になりますが、はじめに書いたとおり、単純に複数のレコードを記述しただけの DNS によるラウンドロビンは、現在はあまり期待できません。DNS 側が対応(問い合わせごとに応答を変えるような仕掛)か、ロードバランサ同士でのクラスタ構成のような物が必要になると思います。アプリケーションによっては、条件によって、旧来のラウンドロビンと同様の動作をする場合もありますが、今後、IPv6 が普及し始めると、アドレスの優先順位は複雑になるので、アプリケーション側による旧来のラウンドロビンに期待するのは難しいと思います。

id:hiroshit1234

ご丁寧な返信ありがとうございます。

JULYさんの日記は読んでいたので本人様からコメント頂けるなんて感激です^^

ご質問の件、下記に回答します。

・TCPの3WayハンドシェイクがFinで終了してから異なるIPアドレスでの通信が始まる

可能性として一番高いのはhtmlのファイルに直接IPアドレスが記載されている

ファイルが存在するのでは、とのことですね。

こちらに関してお客様に確認してみます。

事象の詳細は

1.httpsでIEよりURLへアクセス

2.Topページよりログイン(3フレームに分割された画面が表示される)

3.その内1フレーム内のメニューURLをクリック

4.メニューの選択結果が表示されるはずのフレームに

 「タイムアウトが発生しました」と表示される

となっております。

上記動作を実施したときに、2を実施して時間を空けて(1~30分程度)

3を行ったときはhttpsのコネクションがタイムアウトして

ラウンドロビンで異なるIPアドレスで再度コネクションを張りに行く、

ということは考えられますでしょうか。

2.のログインしたときの振り分けサーバがWebサーバ#1で、3.のメニューを

クリックするときの振り分けサーバがWebサーバ#2だった場合、このような

現象が起こりうるのかと考えております。

一度認証したhttpsのコネクションの保持時間はWindows7・Apacheで

決まっているのでしょうか。

※LBのセッションテーブルの保持時間は25分で設定してます

とりとめない質問で申し訳ないですが、お助け頂けると助かります。

2011/09/19 11:59:05
  • id:okamotoy
     ロードバランサがあるならDNSラウンドロビンは不要ではないでしょうか.
  • id:JULY
    > 上記動作を実施したときに、2を実施して時間を空けて(1~30分程度)
    > 3を行ったときはhttpsのコネクションがタイムアウトして
    > ラウンドロビンで異なるIPアドレスで再度コネクションを張りに行く、
    > ということは考えられますでしょうか。

    新たにコネクションを張る場合、確かに変わる可能性はあります。

    ブラウザでクリックをする動作が入ると、おそらく、ブラウザの作りとしては、そのタイミングで URL から名前解決をする事になると思います。ただ、ブラウザによっては先読み機能があったりするので、必ずそうなる訳では無いと思いますが、愚直に作れば、クリックされてから名前解決を行う事になります。アプリケーションが名前解決をする、という事は、その時に接続先となる IP アドレスが決定される、という事になるので、そのタイミングで何らかの理由で前回と違う IP アドレスを選択する可能性はあります。

    アプリケーション側でラウンドロビン、という話がありましたが、例えば、ブラウザ側が同時に同じホスト名に対して接続する場合に、負荷分散を考えて、1つ目とは別のアドレスを選択する、という実装は考えられそうな気がします。私の日記で登場する Vine Linux の話によると、Firefox は自前で旧来のラウンドロビンを実装している、という話が出ているので、ブラウザ側が気を回して、別の IP を使う可能性は否定できません。

    ただ、あくまでも「新たな TCP コネクションを開始する場合」であって、TCP によるコネクションが続いている間に変更される事は無いはずです。

    気になったのは、

    > 2.Topページよりログイン(3フレームに分割された画面が表示される)

    のところで、認証処理が入っているという事は、セッション情報を Cookie でやりとりしていたりしませんか? だとすれば、ロードバランサ側でセッション情報をうまく裁いてやる必要があります。例えば、認証時に Web サーバ1につながって、Web サーバ1がセッション情報としての Cookie を発行したとします。Web サーバ間でセッション情報を共有するような仕組みをもっていなければ、ロードバランサがセッション情報を把握して、「この Cookie は Web サーバ1が発行したものだから、Web サーバ1へつなぐ」という処理をしてやる必要があります。

    これは、クライアントがつなぎにいく IP アドレスが変わる・変わらないに関わらず、です。この辺は認証処理をどう実装しているかに依存した話になりますが、おそらくはロードバランサ側のマニュアルと格闘する話になると思います。

    > JULYさんの日記は読んでいたので本人様からコメント頂けるなんて感激です^^

    げっ、下手なこと書けなくなっちゃうなぁ(^^;。
  • id:hiroshit1234
    okamotoy様
    インターネット回線の冗長化を行っていてインターネット回線が2回線あります。
    DNSラウンドロビンはどちらのインターネット回線からのでもアクセスできるように
    今回追加機能として実装しました。説明が不足していて申し訳ございません。


    JULY様
    説明が不足していてすいません。
    httpsの認証はサーバーで行っております。LBでhttpsの認証を行い、サーバへ
    httpの通信を振り分けているシステムではおっしゃるとおりLBがクッキーのセッションIDを
    認知しているのでセッションIDによるサーバー振り分けを行っております。
    ですが本システムではLBは受信したhttpsの通信を振り分けているだけなので
    LBはセッションIDは意識せずIPアドレスとポート番号のみでコネクションを管理し
    振り分けております。
    ブラウザの仕様で時間を空けると異なるIPアドレスでアクセスする可能性があるとの
    ことですね。試してみます、ご教授ありがとうございますm(__)m

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません