機器の構築を終え、疑似環境に組み込みいざ総合試験を実施するぞというタイミング。
障害試験中になぜか通信不可になるトリガーの原因が中々わからず少しハマってしまったそんなお話。
Contents
今回の事象のポイント
- ICMPリダイレクトによるルートの最適化
- 上記に伴う特定の条件下における通信不可発生(初回のみ通信が可能状態)
- そもそも構築したネットワーク構成が悪い(同セグ内ルーティング)
ネットワーク構成

障害試験中に起こるイレギュラー

機器構築も終わり、単体試験、結合試験も順調に消化!
オンスケどころかかなり巻きでタスクを消化出来てるし順調だ!
ウキウキの状態で機器の冗長化試験に臨むへびたわ。
この後出会ったこともない現象に直面するとはつゆ知らず…
前述のネットワーク構成において、拠点AのFW配下の運用端末から拠点Bファイアウォール(以降B-FWとする)へpingを打ち続けた状態で拠点Aルータ1(以降A-RT1とする)をシャットダウンを行う。

準備出来たのでシャットダウンお願いしまーす!
一緒に試験を行っている相方に声をかけ、A-RT1をシャットダウンさせる。
A-RT1は自身のVPNトンネルを監視しており、VPNトンネルが切断されたと判定された場合A-RT2へパケットを渡すようにルーティングが書かれている。
しばらくするとB-FWへのpingが回復。想定通りの動きをしていた。


よーし想定通りだな。じゃあ電源入れてもらえますかー?
電源を入れる相方。
拠点AファイアウォールはA-RT1の回復を検知し、再びパケットはA-RT1を経由してB-FWへ運ばれだす。
B-FWへのpingは一度も途切れず、スムーズに回復が行われた。
pingは一度も途切れていない。至って順調。いつもやっていること。何も起きるはずがない。
…否。
全く順調では無かった。
既に異変は起こっていた。だがそれは目には見えない。故にこの時点で気づくはずもなかった。

そしてついにその瞬間は訪れる。

メイン経路の試験は終わったから次はバックアップ経路の試験だ。
バックアップ経路を落とすのは基本何も起こらないから後は淡々と消化するだけだな。
そう。メイン経路が生きている限りバックアップ経路は使われることは無い。
故にその状態でバックアップ経路を落とそうが、何も起きることは無いのだ。
普通はね。

じゃあ二号機落としてくださーい。
相方が二号機を落とした。
その瞬間途絶えるB-FW2へのping。
明らかなイレギュラーである。
原因の特定、調査へ
へびたわはまず配線ミスを疑った。
まずは一番下のレイヤから切り分けていくことは基本である。

インフラエンジニアの基盤とも言えるOSI参照モデル。
https://www.sbbit.jp/article/cont1/12099
まず切り分けが簡単な下層レイヤから調べるのは定石である。
結果、配線ミスは見られなかった。
この時点で何となくどこかの機器のARPテーブルがおかしくなったのかななどと漠然と考えていた。仮想IPや仮想MACが使用される時におかしい動きが起きたら大体重複してたりしますからね。
まあその予想は外れるんですがね。

FWとルータのARPテーブル確認したけど異常は見られない…
じゃあルーティングか。ルーティング洗ってみよう。
■ A-FW → デフォルトゲートウェイがA-RT代表
■ A-RT1 → NW2へのゲートウェイはTunnel1、Tunnel1がダウン時はA-RT2へ
■ A-RT2 → NW2へのゲートウェイはTunnel2
■ B-FW → デフォルトゲートウェイがB-RT代表
■ B-RT1 → NW1へのゲートウェイはTunnel1、Tunnel1がダウン時はB-RT2へ
■ B-RT2 → NW1へのゲートウェイはTunnel2
みなさんは上記ルーティングの違和感に気付けるだろうか?
へびたわは上記ルーティングがおかしいことには気付いていた。
気付いていたが、構成上このようなルーティングを入れるしかなかったため設定していた。
それが今回の事象発生の原因である。

おかしな設定の正体
おかしい設定それは…
■ A-RT1 → NW2へのゲートウェイはTunnel1、Tunnel1がダウン時はA-RT2へ
■ B-RT1 → NW1へのゲートウェイはTunnel1、Tunnel1がダウン時はB-RT2へ
この二つのルーティングである。
今回機器冗長方法として、ルータはYAMAHAのRTX1220を使用してVRRP構成を採用している。
通常VRRP構成を採用する際、バックアップ側のルータへのルーティングなど設定しない。
通常はマスタ側のルータにシャットダウントリガを設定し、マスタ側の経路障害が起きた時はVRRPをシャットダウンすることによって、バックアップ側のルータの代表でパケットを受け取るように切り替えるのである。
つまり、マスタ側の経路障害が起きた時にマスタルータのVRRPが動作し続けていることはおかしいのである。
よって前述のルーティングは通常であれば不要な設定なのである。

この設定を入れなければいけなかった理由は今回割愛しますが、へびたわ自身まさかこの設定が致命的な問題を引き起こすとは思ってもいなかったのです。
不要な設定が入っていることによって起きたこと
上記のルーティングは所謂「同セグ内ルーティング」と呼ばれるものである。
このルーティング非常に好ましくないルーティングなんですね。
このルーティングを入れると通らなくてもいい経路を通ることになります。
下の図を見てください。
A君、B君、C君は同じ部屋にいます。
ただ、A君がC君に荷物を渡すときは一度B君に渡すように指示がされています。

ただ、これって無駄ですよね?
それに気づいたB君。B君は初回はA君からの荷物を受け取りC君へ渡します。
その際B君はA君に向かって、「次回以降は僕に渡すんじゃなくて直接C君に渡すといいよ。」と助言します。
A君はその助言を受け取り、次回以降はB君へ荷物を渡さず直接C君へ渡すようになります。

この助言。
専門用語で「ICMPリダイレクト」と呼ばれます。
ICMPリダイレクトとは、L3デバイスがパケットの送信元ホストに、特定の宛先ネットワークに対する適切なゲートウェイを通知する機能のことです。
https://www.infraexpert.com/study/fhrpz12.html
このICMPリダイレクトによって今回の通信不可状態は引き起こされました。
ICMPリダイレクトによって引き起こされていたこと
前項で触れたようにICMPリダイレクトが有効だと、受け取ったホストは本来のルーティングに加えて自身のルーティングテーブルに一時的なリダイレクトルートを追加します。
今回の構成の場合、各RT1がFWに対してICMPリダイレクトメッセージを送信し、それを受け取ったFWはRT2へのリダイレクトルートを保持してしまったということですね。
これが今回の事象を引き起こした原因というわけですね。
これに気付いたきっかけは以下の二つです。
- パケットキャプチャをしたところICMPリダイレクトパケットが大量に送信されていたこと。
- tracerouteで経路を調べると戻りのルートがRT代表ではなくRT2に直接ルーティングされていたこと。

困ったらとりあえずパケットキャプチャですね。毎回乗り気ではないですが…
対処方法
ルータ四台に以下の設定を追加しました。
※本ルータはYAMAHA RTX1220です
ip icmp redirect send off
これで解決。

おわりに
いかがだったでしょうか?
「ネットワーク構成が悪い+普段意識しないICMPリダイレクト」のコンボに見事にやられ、丸々三日ぐらい稼働を使ってしまいました…
ですが、トラブルに出会ってこそ成長のチャンス。これでまたへびたわは賢くなったのであった。

そんなことより良いネットワーク構成考えろって話ですね。
ここまで読んでいただきありがとうございました!
また次の記事でお会いしましょう!

