以前から自宅のIPv6が不安定だったが、ようやく原因がわかり安定してIPv6を使えるようになった。 もっと早くにきちんと調べていればすぐ解決できる類の問題だったので、解決してすっきりというよりこんなことかという落胆の方が大きいが、同じ失敗を繰り返さないように頑張って記録を残す。

原因は、FortiGateのSD-WANがインターネットへ疎通できないゲートウェイへトラフィックを振り分けてしまっていたことだった。

障害に備えてゲートウェイを2つ用意しており、IPv4では両方ともインターネットへ疎通可能だがIPv6では片方のみインターネットへ疎通可能(ゲートウェイとは両方疎通可能)な状態である(※1)ため、IPv6についてはパフォーマンスSLAによりインターネットと疎通可能なゲートウェイを選択する想定でいた。

ここで、SD-WANルールにある暗黙のルール(デフォルトの挙動)の振り分け先にもパフォーマンスSLAでDownと判定されたゲートウェイの情報が反映されると思っていた(パフォーマンスSLAの「スタティックルートのアップデート」を有効にしていたため)が、どうやら反映されないようで、diagnous debugで調査するとDownしているゲートウェイへも振り分けられていたことがわかった。 両方のゲートウェイがインターネットへ疎通可能なIPv4で挙動を確認した結果、以下の通りであった。

• パフォーマンスSLAの検知で片方のゲートウェイがDownとなるように上位ルータのフィルタを設定(検知以外のトラフィックは疎通可能)する。
  • パフォーマンスSLAで片方Down判定となるが、Down判定されたゲートウェイへ転送されていたトラフィックは変わらずDown判定のゲートウェイへ転送され続け疎通できた。
• SD-WANでゲートウェイに指定している上位ルータのインターフェースを片方Downさせた。
  • パフォーマンスSLAで片方Down判定となり、Down判定されたゲートウェイへ転送されていたトラフィックは変わらずDown判定のゲートウェイへ転送され続け、疎通できなくなった。

パフォーマンスSLAで検知しようがインターフェースが落ちようが、暗黙のルールによる振り分け対象からは除外されないらしい。 インターネットへ疎通可能なゲートウェイのみ動的に選択し、かつ複数ゲートウェイが疎通可能な場合にトラフィックを分散させるには、インターフェース選択戦略に最小コスト(SLA)を指定した上でロードバランシングの項目を有効にしたSD-WANルールを追加する必要があるようだ。 なお、Downしているインターフェースが暗黙的に選択される可能性を何のために残しているのかは不明。

ひとまず上記のSD-WANルールを追加したことにより、パフォーマンスSLAの結果でゲートウェイを選択し、かつバランシングされるという期待した挙動を実装できた。

解決が難しかった(あまり真面目に調べていなかった)理由として、事象の再現性が低かった点が挙げられる。 暗黙のルールを送信元IPアドレスと宛先IPアドレスの組み合わせで振り分ける設定としていたため、 何も変更していないのに宛先の変化によって疎通できる・できないが変化してしまっていた。

送信元のみで振り分けていれば疎通可能な状態と疎通不可の状態がもう安定し、早期解決に繋がった...かもしれない。 エンドポイントを疑ってさらに混乱した...かもしれない。

また、IPv4は疎通可能であるため困っていなかったといのもひとつの要因。 もう少し真面目にIPv6使うべきか...？

※1: IPv6は配布される/56のPrefixをdelegationしているが、確認した限りFortiGateにおけるIPv6のdelegation設定では1つのupstreamしか設定できなそうだったため。IPv6の使用を優先して冗長構成について調べきれていないので、もっと良いやり方があるかもしれない。