VPNサイトでルーティングループとルートフラッピングを見分ける方法
ルーティングループとフラッピングするルートは同じ断続的な損失を引き起こします。ゲートウェイでの三つの確認で、何かを変更する前に両者を区別できます。
二つのサイト、一つのトンネル、そしてしばらく応答してから沈黙するリモートプレフィックス。反射的にルーティングループと呼びたくなりますが、実際にそうであることもあります。しかしループとフラッピングするルートは同じ苦情を生み、必要な修復は正反対です：一方は決して終わらない転送判断であり、もう一方はテーブルから離れ続けるプレフィックスです。三つの観察が両者を分け、フィルタに触れる前やトンネルを再起動する前に、その三つすべてをゲートウェイのコマンドラインから集められます。
ループはホップごとに決まります。サイトAが宛先のネクストホップとしてBを選び、Bが同じ宛先にAを選ぶと、パケットは二往復ののちTTLで失効します。フラッピングは代わりにルーティングプロトコルが決めます：プレフィックスが撤回され、再インストールされ、あるいは代替のネクストホップに置き換わるため、ルートがまったくないパケットもあれば、まったく正常なルートをたどるパケットもあります。
問題を決着させる三つの確認
最初の判断にパケットキャプチャは要りません。両端のプレフィックスの状態、各側が選ぶネクストホップ、そして繰り返すかどうかのホップ数があれば足ります。トラフィックが失敗している間もプレフィックスが同じネクストホップでインストールされたままであれば、ループは転送経路にあります。プレフィックスが消えて戻るなら、障害は転送より上にあり、修復は静的ルートではなくルーティングプロトコル側です。
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
始める前の警告が一つ。ループしているトンネル越しにこれを読んでいるなら、ルートを変えた瞬間にセッションが切れます。修復しようとしているプレフィックスに依存しないコンソールか管理経路を開いてください。
確認その一: プレフィックスは安定しているか、揺れているか
設定ファイルが約束する内容ではなく、カーネルが何をインストールしたかを尋ねます。Linuxゲートウェイでは、ip route get 10.20.30.40 がポリシーテーブルを含め転送経路と同じ検索を実行し、ip route show 10.20.30.0/24 はエントリ自体を表示します。ip monitor route は変更を起きた瞬間に流すので、プレフィックスの出入りを監視する最速の方法です。
FRRやBIRDを動かすルーターでは、興味深いのは転送テーブルではありません。show ip bgp 10.20.30.0/24 は選択された経路とその稼働時間を返します：数分ごとにリセットされる稼働時間は、名前を付けられるフラッピングであり、ループではありません。show ip bgp summary は隣接の状態とプレフィックス数を表示するので、落ち続けるピアは転送経路から疑いを外します。
何かを変える前に答えを書き留めます。pingが失敗している間に十分間安定していたのか、十分間で四回消えたのかで、次の手順は変わります。後者なら静的ルートの理論はすべて無意味です。
確認その二: ネクストホップは到着トンネルへ戻っているか
ループには二つのゲートウェイの合意が必要です。パケットを受け取るサイトで、ポリシールールがメインテーブルと違う答えを返すことがあるため、実際の送信元アドレスを付けた ip route get 10.20.30.40 from 10.10.5.20 でパケットが出ていく経路を見ます。次に、送信したサイトでも同じ検索を繰り返します。両側が同じプレフィックスのネクストホップとして互いを選ぶなら、ループは証明され、キャプチャを足しても何も増えません。
原因はほぼ常に トンネルを越えるべきではなかった広告 です。トンネルに再配布されたデフォルトルート、リモートサイト自身のサブネットを覆う集約、念のためのピア向け静的ルートは、いずれも同じ相互のネクストホップを作ります。トンネルが完全に確立していてもトラフィックが輪を描くことはあり、strongSwanの転送に関する注記がその要件のルーティング側を説明しています。
WireGuardには、責めるべき広告が存在しないため、独自の注記が必要です。wg show は各ピアのAllowedIPsを列挙し、カーネルはその範囲内にある宛先だけをピア宛てに受け付けます。そこでのループは重複したAllowedIPs範囲か、インターフェースを越えて戻る静的ルートであり、修復はその二か所だけにあります。
確認その三: 星ではなくホップ数を読む
traceroute -n -I 10.20.30.40 と mtr -n -r -c 20 10.20.30.40 はどちらも経路を示し、ICMPモードはUDPプローブを食べるフィルタをしばしば生き延びます。ループは同じ二つのゲートウェイアドレスが短く繰り返し、TTLが毎回上がる形に見えます。ドロップは応答した最後のゲートウェイの先が星の形に見え、一つの沈黙したホップは何の証拠にもなりません。
経路が曖昧なときは、ワイヤ上のTTLを読みます。両方のゲートウェイで tcpdump -ni any -vv icmp を使うと、各パケットのTTLと、時間超過の返答ごとの送信元アドレスが見えます。パケットが経路に含まれ得るホップ数より低いTTLで遠隔サイトに届くなら、tracerouteが見せていないホップを何かが追加しており、これは一方のサイトのファイアウォールが他方の代わりにプローブへ応答するときに起こります。
プレフィックスの所有者を直し、それから両方向を検証する
どのサイトが宛先を生成し、どのトランジット経路が許可されるかを決め、その所有者の広告か静的ルートを変更します。受信側のサイトを直すのは魅力的で、たいてい間違いです：一つのプレフィックスのループを隠し、次のプレフィックスのために悪い広告を残すからです。ルートタグ、ディストリビュートリスト、スプリットホライズンの規則はこれを発生源で止めるためにあり、単一のプレフィックスに一致するフィルタより安く済みます。
変更後は、ループがブラックホールに置き換わっても症状が見た目に改善しないことがあるため、往路と復路を別々に検証します。両端から ip route get を実行し、ゲートウェイではないホストからトラフィックを送り、少なくとも一つのホールドタイマーの間 ip monitor route を動かしたままにして、フラッピングを修復と取り違えないようにします。
何かを変える前に、次の五点を確認します：プレフィックスが安定しているか揺れているか、両端のネクストホップがトンネルを指しているか、ホップ数が繰り返すかどうか、プレフィックスを所有するサイトが一つか、変更に耐える管理経路を持っているか。五点のどれかが不明なら、残りの四点は推測です。