①事象

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

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

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

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

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

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

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

この getaddrinfo() の場合、IPv4、IPv6 を含めて、候補となる IP アドレスのリストが返ってきます。対応するアドレスが１つしか返ってこない 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 が普及し始めると、アドレスの優先順位は複雑になるので、アプリケーション側による旧来のラウンドロビンに期待するのは難しいと思います。