テーブル200のVPNデフォルトがLANルートを隠す

ポリシーテーブルの不具合とルーティングの不具合は、どのルールが一致したか、そのルールが指したテーブルはどれか、そのテーブルに何が入っているか、その中でどのルートが勝ったかという四つの確認で切り分けられます。先行するテーブルがルートを返すとメインテーブルは参照されないため、そこに見えているLANエントリがテスト対象のパケットには無関係であり得ます。確認を順に進めれば、欠けているルートは四番目ではなく三番目の手順で見つかります。

最長プレフィックス一致は一つのテーブル内で行われ、すべてのテーブルのルートを単一のリストとして比較するわけではありません。

検索は最初に応答したテーブルで終わる

あるサブネットのトラフィックがまずテーブル200を参照し、テーブル200にトンネル経由のデフォルトルートがあり、メインテーブルにLANプレフィックスがあるポリシーを考えます。LANアドレス宛のパケットは、テーブル200のそのデフォルトに一致してそこで止まることがあります。検索がルートを返したため、後にあるメインテーブルのルールがより具体的なエントリを提示する機会はありません。結果として、まったく問題のないLANルートが使われないまま、パケットはトンネルに入ります。

先行するルールとマシン自身のローカルアドレス検索は依然として適用されるため、テストには実際のフローが持つ送信元、マーク、インターフェースを使う必要があります。別の条件で問い合わせるとLANが正しく選ばれ、探している不具合そのものが隠れてしまいます。

LANの例外はふさわしい場所に置く

選択したテーブルは必要とするLANルート、接続ルート、エンドポイントルートを保持でき、それによってポリシーは自己完結します。別の設計では、LANプレフィックスに対する明示的な先行ルールを使うか、プレフィックスを後続の検索に渡す意図的なスロールートを使います。どれも所有者の異なる正当なパターンです。どちらが短く書けるかではなく、意図したポリシーとルートの保守担当者で選びます。

どのパターンであっても、例外はポリシーが定義されている場所で見える必要があります。手で追加し記録していないルートは次回の再起動で消え、診断も一緒に失われます。

メインテーブルを丸ごとコピーしない

メインテーブルのすべてのルートをポリシーテーブルにコピーすると、修正に見えてスナップショットが生まれます。管理者はアドレスやインターフェースを動的に追加・削除でき、コピーは誰も気づかないうちに古くなります。ルートのライフサイクルは設定の所有者に任せ、テーブルはある時点ではなく設定から再生成してください。

コピーしたテーブルは、ポリシーが制約するはずだったフォールバック動作を再現するため、目的も損ないます。

応答はルートとは別に確認する

検索が意図した経路を選んだ後でも、応答はテーブルと無関係な理由で失敗することがあります。変換が誤ったインターフェースに適用されたり、逆経路検証が予期しない経路で届いたパケットを拒否したり、エンドポイントが単に応答しないこともあります。これらは別の証拠を持つ別の不具合であり、ルートエントリを編集してもどれも直りません。

変更の両側で、まさにそのフローの検索結果を保存し、修正が見えるようにします。逆経路検証を全体で無効にしたりルールをフラッシュしたりしても、欠けたルートは得られず、無関係な制御が弱まります。

ルール、テーブル、勝ったルート、応答経路を記録します。その記録が、ポリシーの誤りと壊れたサービスを分けます。