トンネルは稼働中、経路は消えた：2つのVPN障害を切り分ける

トンネルインターフェースが確立済みと報告し続ける一方で、あるホストに到達できなくなる。この二つの観測は矛盾しない。何かがトラフィックの使っていた経路を外した。隣接がプレフィックスを撤回したか、追跡していたスタティックルートが外れたか、別のルートが優先されたのだ。セキュリティアソシエーションは三つのどの場合でも完全に健全でありうる。出来事を切り分けるとは、VPNが失敗したかではなく、どの層が最初に変わったかを問うことだ。

一つの出来事に見える三つの段階

ルーティングの判断には三つの段階がある。プレフィックスを受信し、最良として選択し、転送テーブルにインストールする。各段階は単独で失敗しうるが、アプリケーション側から見れば失敗は同じに見える。学習されたが選択で敗れたプレフィックスは、転送テーブルだけを見ている限り、決して届かなかったプレフィックスと区別できない。

だから最初の問いは、どのプロトコルが悪いかではなく、どの段階が壊れたかである。答えによって、インシデントの担当者と次の確認に使う道具が決まる。

まずインストールされた経路を読む

カーネルに、障害の起きている宛先へのトラフィックが実際どこへ行くのかを尋ねる。ip route get はネクストホップ、インターフェース、カーネルが使う送信元アドレスを表示し、テーブル全体ではなく一つの宛先について答える。答えがトンネルを示すなら、転送テーブルはまだ経路が存在すると信じており、問題はその上にある。

ip route get 10.20.5.10
ip route show 10.20.0.0/16

「unreachable」という答えは、インストールされた経路がまったくないことを意味し、撤回かインストール漏れを示す。物理インターフェースを示す答えは、誰も決めないままトラフィックがトンネルを出たということであり、次の確認は勝った優先度である。パケットが消え続けているのにトンネルを示す答えは、経路のさらに下、フィルタリングか遠端を示す。

次にプロトコル自身の見え方を見る

ルーティングデーモンは複数のテーブルを保持しており、興味深い比較はその間にある。BGPでは、隣接セッションの状態、受信した広告、インストールされた経路が三つの別々の証拠になる。プレフィックスは受信テーブルにとどまったまま、より短い管理距離の経路が勝つためカーネルに届かないことがある。相手側が広告をやめたと結論づける前に、三つすべてを確認する。

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

サマリーはセッションが確立しているかを、プレフィックス単位の表示はそのプレフィックスが受け入れられたかを、カーネルの検索はインストールされたかを教える。この順に読めば、セッションの揺らぎを撤回と、撤回をポリシーによる拒否と取り違えずに済む。

時計が食い違うとき

トンネルのログ、ルーティングのログ、アプリケーションの最初の障害を、実際のタイムゾーンで一本の時間軸に置く。隣接の喪失が先なら、トンネルが経路を道連れに落とした。撤回が先なら、ルーティングが変わり、トンネルはその後で反応した。これは担当者の異なる別々のインシデントであり、順序が発見のすべてである。

一分の時計のずれでその結論は逆転するので、順序を信じる前にタイムゾーンとオフセットを確認する。オフセットなしのローカル時刻でログを取る機器は、自信ありげで間違った時間軸のよくある源だ。

ループのない復旧

撤回の後、適格な経路は二つありうる。プロトコルが選ぶ経路と、手で固定する経路だ。ネットワークがあなたの代わりに決め続けるのは前者だけであり、だから手動経路は復旧計画ではなく暫定措置である。代替の広告も、すでに確立したセッションのファイアウォールやNATの状態を保持しないので、元のフローが壊れたまま新しいフローだけが動くことがある。どちらのバックアップを有効にすべきか、遠隔サイトがそれを通る戻り経路を受け入れるかを確認する。

撤回が起きた理由を理解する前に、恒久的なスタティック上書きをインストールしてはいけない。その近道はトラフィックを故障した経路に固定したり、意図的なルーティングポリシーを静かに迂回したりしかねず、元の原因を新しい設定の下に埋めてしまう。経路が復旧したらアプリケーションを再試験し、選んだプレフィックスにテーブル上の項目だけでなく実際に機能するデータ経路があることを確認する。