はじめに
「本番環境でやらかしちゃった人 Advent Calendar 2020」に掲載する候補の1つだったけど、別にユーザ影響は与えてないからやらかしちゃってないなぁ～と思ってボツにした記事。
せっかく載せる記事の候補をリストアップしたので、公開してみようと思います。
システムの概要
とあるシステムの全面更改案件があり、その時はネットワークチームのリーダとして案件に関わっていました。
元々のシステムの構築は別ベンダが担当しており、システム更改でベンダ変更を行うという案件になります。
ネットワーク構成としては、フロントエンドでWeb系通信を受け、バックエンドで各システムと連携するといったごく一般的な構成になります。
但し、Web系通信はインターネット通信網が2つあり、それぞれ別のページを表示させるような構成となっておりました。
インフラ試験では出なかったのに
各フェーズすべて波乱万丈でしたが、、、試験フェーズまで辿り着き、何とかインフラ試験を終わらせて、アプリを入れた総合試験を実施時に問題が発生。
httpでアクセスしたとき、httpsにリダイレクトさせる総合試験で、一部端末だけhttpsにリダイレクトされないという問題が発生。
Webサービスのリダイレクト設定が間違ってるのかな？と当たりをつけて見てみるものの、設定上はうまくリダイレクトできそう。
パケットキャプチャによるシーケンス調査
問題を追えないなら、パケットを追えばいい！
ということでパケットキャプチャを取ってサクッと調べてみると、Webサーバから想定通りのレスポンスは返している模様。
Webサーバの前にいる負荷分散装置は・・・正常にレスポンスを返しているようだけど、、、ん？
送信パケットと応答パケットを受け取っているインタフェースが違う！
今更ルーティングが抜けていたのか？と不安に感じながら現行のルーティング定義と見比べても、足りないルーティングは無く、差分は無いように思える。
問題の原因
結論としては現行環境で使っていたBIG-IPと今回導入した負荷分散装置の仕様の違いでした。
現行のBIG-IPではAuto Last Hopという機器仕様でうまいことレスポンスパケットを返していたのですが、今回導入した機器には機能が無かったので、試験フェーズまで発覚しなかったということでした。
Auto Last Hopの詳細は以前書いた以下をご覧ください。
※今回の件のことを書いてます。
解決案の検討
仕様の違いはどうしようもないとして、今回の機器にはAuto Last Hopと同じような機能は無く、別の方法を考えなければ・・・
ここまで来て、BIG-IPに買い替える事なんてできない！！
その１ 仮想ルーティング案
Cisco機器で言うところの、VRF(Virtual Routing and Forwarding)のような機能でルーティングテーブルを複数持てれば回避できるのでは！と思い調べてみたけど機能なし。
その２ ポリシールーティング案
負荷分散装置からネットワーク網にレスポンスパケットを返す際、ポリシールーティングで制御すれば回避できるのでは！と思い調べてみたけど以下略。
・・・ネットワーク機器ならポリシールーティングくらいできても良いと思うんだ（愚痴
その３ NAT案
アドレス変換すれば何とかできるのでは！と思い調べてみたけど、1対1で変換できるような数ではなく、1対多で変換したとしても、追跡が難しくなり、監査要件が満たせなくなるのでボツ。
あといくつか案を考えた気がしますが、どれもうまくいかずボツ。
最終的に
どうしようもないので、負荷分散装置とネットワーク網のルータ間に1本リダイレクト用ケーブルを敷設させて頂き、「BIG-IPのAuto Last Hop機能には気をつけろ！！」でも書いた通り、ルータでポリシールーティングをゴリゴリ書くことで回避しました。
おわりに
機器固有の機能など使っていたり、特殊な方法で問題を回避していたような場合、移行時に思いがけない問題が発生することがあります。
今回はオンプレ機器で自システム内の機器設定を工夫することでどうにかできたからよかったですが、もしクラウドへの移行等でこのようなネットワークの問題が発生した場合はクラウド側で対応しきれず、影響が大きくなるのではないかと思います。
クラウド移行だけの話ではないですが、移行時には、機器の仕様やトリッキーな設定に注意しましょう。