VPN のルートテーブルが教えてくれることと教えてくれないこと

接続してルート一覧を実行すると、聞いたこともないサブネットがトンネルを指しているのが見えます。その行は一つのことを正確に述べ、いくつかのことについては何も述べていません。このマシンがそのプレフィックスにパケットをどう転送するかを記録しているだけで、そこにどのホストが存在するかは何も、あなたのアカウントが何に到達できるかも何も示しません。正しく読むには一分で足りますが、一覧として読む癖を抜くにはずっと時間がかかります。

テーブルをローカルの指示として読む

ルートはローカルカーネルが保持する転送指示で、このプレフィックスにはこのインターフェースとこのネクストホップを使うという意味です。プレフィックス長が指示の具体性を決め、最長一致が優先されます。その規則には権限もサービスの状態もリモートのトポロジーも書かれていません。

ポリシールールはテーブルを参照する前に介入することがある、だからこそルートが存在しても、あるパケットが実際に使うルートとは限りません。ルールをテーブルと並べて読み、そのうえで特定の宛先にどの経路を選ぶかをカーネルに尋ねてください。一つのアドレスに対する答えは、一ページ分のプレフィックスより価値があり、クライアントが適用したマーク、名前空間、インターフェースの紐付けを反映する唯一の答えです。

広いプレフィックスはカタログではない

トンネル経由でルーティングされた /16 は、一万六千台の到達可能なホストを意味しませんし、デフォルトルートはさらに意味がありません。何が応答するかはサーバーが、何が許可されるかはファイアウォールが、何が認可されるかはアカウントが決めます。

狭いテーブルには逆の罠があり、プレフィックスがないことは、宛先が別の経路で到達できることを意味する場合もあれば、単にまったくルーティングされていないことを意味する場合もあります。その二つは試すまで同じに見えます。テーブルは、VPN に何が含まれるべきかという期待ではなく、使うように言われたリソースと比べてください。

エントリはどこから来るのか

ルートは少なくとも四か所から来ます。設定ファイル、接続確立時にルートをプッシュするサーバー、インターフェースを所有するネットワークマネージャー、そして障害対応中にコマンドを打つ人で、それぞれ寿命も所有者も異なります。

障害中に打ったルートは、再起動で消えるルートであり、誰の文書にも残りません。サーバーがプッシュするルートはサーバーが変われば変わるので、説明のつかない新しいプレフィックスはクライアントの変更後ではなく、ゲートウェイの更新後に現れがちです。ip-route のマニュアルには、フラグを読む必要がある場合のテーブルとフィールドの構文が記載されています。

ルートをサービス契約と突き合わせる

有用な比較は、テーブルと約束されたサービスの間で行います。名前、アドレスの範囲、ポート、所有者であり、この四つをプレフィックスの横に書けば、隙間が見えてきます。

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

プレフィックスがあり、それでもサービスが失敗するなら、テーブルは役目を果たしており、問題は名前解決、向こう側のファイアウォール、正しいグループのないアカウントなど別の場所にあります。プレフィックスがないなら、問うべきは誰が用意すべきだったかであり、何を入力するかではありません。どちらの答えも次に尋ねるチームの名前を示し、それがルートテーブルを読む唯一の有用な成果です。ターミナルを閉じる前にその名前を書き留めてください。

変更の前後を、日付とインターフェースとともに記録してください。ルートテーブルは一台のマシンの一瞬のスナップショットであり、いつ取得したかを誰かが書き留めて初めて証拠になります。