VPN 経由で OSPF ネイバーが確立しない？ この順に確認する

トンネルは上がっており、インターフェースも同じサブネットにあるのに、OSPF は何も表示しません。多くの場合トンネルは正常で、OSPF の要件が一つ満たされていません。以下の五つの確認を順に行い、最初に失敗した項目で止めてください。

各確認にはそれぞれ異なる症状があるため、一覧そのものより順序が重要です。

確認 1：リンクモデルは正しいか

ポイントツーポイントインターフェースと共有マルチアクセスネットワークは別の OSPF 環境です。ブロードキャスト LAN の設定をトンネルにコピーするのが、ここで最も多い誤りです。VPN 実装がサポートするネットワーク種別を設定します。ルーティングされたトンネルなら通常はポイントツーポイントです。その後、プラットフォームがその設定に同意しているか確認してください。実装によっては設定を無視したり上書きしたりします。

リンクモデルが誤っていると、一覧の後の項目はどれも役に立ちません。

確認 2：パケットは通過を許可されているか

OSPFv2 は IP プロトコル 89 であり、TCP や UDP のポートではないため、ポート向けに書かれたファイアウォール規則では黙って破棄されます。Hello はマルチキャストアドレスにも送られ、ポリシーが許可していない場合があります。トンネルの両端間でプロトコル 89 を許可し、その後プラットフォームに明示的なネイバー設定が必要か確認してください。

ping だけが通るトンネルはポリシーの問題であり、ルーティングの問題ではありません。

確認 3：ネイバーパラメータは一致しているか

エリア ID、hello と dead の間隔、認証、stub フラグはすべて一致している必要があります。不一致があると、通常は黙って失敗するのではなく可視状態で止まるので、それ自体が手がかりになります。比較するのは両端で実際に動作している設定であり、意図した設定ではありません。

見落としやすいのが MTU の不一致です。ExStart でデータベース交換を妨げるため、ネイバーは Full に到達しません。

確認 4：状態は何を語っているか

状態が障害を名指しします。Init は hello が届いているもののこのルータが一覧に含まれていないことを意味し、片方向経路かマルチキャストの問題を示します。Two-Way は非 DR ネイバーがいるブロードキャストセグメントでは正常、ポイントツーポイントリンクでは異常です。ExStart や Exchange で止まる場合は MTU かデータベース記述の問題です。Loading はリンクステート要求に応答がないことを意味します。

何かを変更する前に状態を読み取ってください。一覧の大半はそれで除外できます。

show ip ospf neighbor は状態、ネイバーアドレス、dead タイマーを表示します。そのタイマーを両側の hello 間隔と比較してください。dead が hello の四倍なら正常で、それ以外は不一致です。状態の列はページ全体で最も速く読める情報です。

確認 5：実際に何が広告されているか

Full 隣接はルートではありません。どのネットワークが生成され、どれが学習され、どれがルーティングテーブルにインストールされているかを確認してください。network ステートメントの欠落や、サイトのプレフィックスを除外する再配布ポリシーがあると、ネイバーは正常なのにテーブルが空になります。

次にホストレベルのアプリケーションと戻り経路をテストしてください。ルーティングプロトコルはファイアウォールを開けません。

IPv6 の場合、OSPFv3 には独自の要件があり、OSPFv2 の各設定に対するアドレスファミリの切り替えではありません。対応するプロトコルとプラットフォームのドキュメントを使用してください。また、接続が固定リンク一本だけなら、運用負担の増えるコントロールプレーンを追加する前に静的ルートと比較してください。