LinuxでVPNがプッシュしたルートと静的ルートを見分ける方法
トンネルとともに現れるプレフィックスには三つの出所があります。表を比較し、メトリックを確認し、それを何度も入れ直す出所を直してください。
トンネルが上がるとラップトップにあるプレフィックスが現れるので、VPNが入れたように感じます。実際そうかもしれませんが、同じ結果は接続時に走るクライアントスクリプト、サブネットを列挙する接続プロファイル、あるいは最初から存在していてインターフェースができて初めて機能し始めた静的ルートからも得られます。出所を間違えると、掃除のたびにルートが戻り、次の担当者が同じ修正を繰り返します。以下の手順は、何かを変える前にこの三つを切り分けます。
ステップ1:プレフィックスを入れる仕組みに名前を付ける
プロトコルによって到達可能性の与え方は異なり、それをすべて広告と呼ぶと区別が隠れます。OpenVPNサーバーは制御チャネルでルート指示をプッシュし、pullフィルターが遮らない限りクライアントがそれを入れます。WireGuardの設定は許可プレフィックスをローカルに列挙し、クライアントは暗号鍵ルーティングと自分が追加するルートの両方にそれを使います。IPsecトンネルはピアとトラフィックセレクターを合意し、カーネルはそのセレクターからルートを入れます。
どの表を読む前にも、自分のトンネルがそのどれを使うかを特定します。接続時にプッシュされるルートはルーティングプロトコルの広告ではなく、プレフィックスが遠端の先で到達可能だという約束もありません。修正がどこに属するかを決めるので、プレフィックスの隣に仕組みを書き留めます。
ステップ2:接続をまたいで表を比較する
トンネルを下ろした状態でメイン表を保存し、上げてからもう一度保存し、二つの取得結果を比べます。現れたものは接続のライフサイクルに属し、残ったものはローカル設定に属します。
ip route show table main > /tmp/route-down.txt で取得し、接続してからもう一度取得します。サイトがIPv6を使うなら ip -6 route でも同じことをします。そこでの欠けたプレフィックスは、ルーティングとは無関係に見える障害を生むからです。
ステップ3:有無だけでなくメトリックを読む
同じプレフィックスの二つの項目は共存でき、カーネルは低いメトリックを選びます。メトリック50の静的ルートは、両方が見えていても100のプッシュされたルートに勝ち続けます。だから「ルートがある」と「通信がそれを使う」は別の命題です。
ip route get 10.20.5.7 でカーネルに直接尋ね、報告されるインターフェースを読みます。トンネルのルートが表にあるのに通信が物理アダプターから出ていくなら、それを説明するのはメトリックかプレフィックス長であり、VPNクライアントではありません。トンネルの先にあると分かっているホストと、そうでないと分かっているホストで同じ検索を繰り返すと、分割が意図どおりに動いているかが分かります。
ステップ4:トンネルより長生きする項目を見つける
静的ルートは設計上切断を生き延び、そこから古い項目が生まれます。存在しないインターフェースを指す固定ルートはサブネットを静かに飲み込み、再利用されたインターフェース名を指すルートは再起動後に私的な通信を間違った扉から送り出します。
固定側は、お使いのディストリビューションが使う場所で確認します。systemd-networkdのユニット、NetworkManagerのプロファイル、クライアントのupディレクトリのスクリプトのいずれかです。ip route del で稼働中の表を直しても次の接続までしか持ちません。その削除は修理ではなく仮説の検証として扱います。
遠端が誤った範囲を出している場合は、すべてをフィルタリングするのではなく運用者に上げます。プッシュされた設定をすべて捨てると、プロファイルが依存するDNSと分割トンネルの方針も捨てることになります。
ステップ5:クライアントを責める前に戻り経路を確認する
サイト間接続やトンネルの先のサブネットでは、遠端にクライアントのアドレスへの戻りルートとゲートウェイでの転送有効化が必要です。片道の経路はクライアントのルーティング不具合とまったく同じに見えます。ただしハンドシェイクと外向きパケットはどちらも成功します。
逆経路フィルタリングはLinuxゲートウェイにもう一つの罠を加えます。ルートが予測するのと別のインターフェースに届いた応答は厳格モードで落とされ、二つの事業者を通る非対称な経路がそれを確実に引き起こします。原因がフィルタリングかどうかは、クライアントではなくゲートウェイのドロップカウンターが教えてくれます。
ステップ6:pingではなく資源を試す
選んだルートが正しくなったら、実際の資源を開いて戻りの通信を確認します。pingの応答は一方向の経路を示すだけでサービスについては何も示さず、キャッシュされた接続に応答するサービスはさらに何も示しません。
そのうえで再接続のあとに確認全体を繰り返します。この手順の価値は次の接続が何をするかを予測できることで、だから比較とメトリックの両方がチケットに属します。