ローカルルートが VPN のデフォルトルートに勝つ理由

机の上のプリンターはトンネルが上がった後も動き続け、別のオフィスのサーバーは静かにローカルの何かに解決される。どちらの挙動も同じ規則から来る。最も具体的なルートが勝ち、直接接続されたプレフィックスは可能な限り具体的だからだ。通常はそれが望む設計であり、重複したプライベート範囲が遠隔アドレスを奪う仕組みでもあり、まずカーネルの選択を読めば不可解な失敗がプレフィックスの比較に変わる。

接続されたプレフィックスはデフォルトルートより具体的

トンネルは通常デフォルトルートか一連のプレフィックスを設定し、ローカルインターフェースは接続されたプレフィックスと LAN 全体へのルートを持つ。両者の間は最長プレフィックス一致が決めるので、LAN プレフィックス内の宛先がトンネルに届くことはない。だから VPN が上がっていてもプリンター、ルーターの管理画面、ローカル NAS は到達可能なままだ。重複する範囲内の遠隔リソースが間違ったマシンに向かうのも同じ理由である。

プライベートアドレス空間は一意ではなく、二つの拠点が同じプレフィックスを選ぶことは計画に入れるべきほどよくある。範囲が重なるとローカルの答えが速く届き、権威ありげに見えるので、失敗をログインの問題と読み違えやすい。宛先は確かに答えたが、意図したものではなかった。

カーネルが下す選択を読む

テーブルを上から読むのではなく、正確な宛先にカーネルがどのルートを使うかを尋ねる。次に、別のテーブルを選びうるポリシールールを探す。二つのコマンドでどちらの問いにも数秒で答えが出る。

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

最初の出力はインターフェース、次のホップ、そしてカーネルが使う送信元アドレスを示し、これが重要な答えである。ローカルブリッジを指す dev の値は、VPN クライアントの状態パネルが何を主張しても、パケットがトンネルに入らないことを意味する。絞り込んだテーブル一覧は別のテーブルが同じプレフィックスを持つかを示し、ルール一覧はそれらのテーブルが参照される順序を示す。ポリシールールはプレフィックスを特定のテーブル経由で送れる メインテーブルと食い違う場合でもそうであり、その順序も答えの一部である。

ローカルアクセスは別個の許可

ルートがあることと、それを使ってよいことは同じではない。ほとんどのクライアントはトンネルが上がっている間ローカルネットワーク通信を遮断でき、その設定はルーティングの副産物ではなくポリシーの判断である。信頼できる近くのサービスが設計に含まれるなら、ルートをでっち上げるのではなく対応するローカルアクセス機能を有効にする。端末が公共 Wi-Fi にあるなら、それは切っておく。

二つの層は違う形で失敗する。遮断されたローカル経路はルートが存在してもタイムアウトを生み、重複したルートは間違ったホストからの応答を生む。両者を見分けるのに問い合わせは一つで済み、ファイアウォール変更の午後が節約でき、転送の取り決めは strongSwan の転送に関する注記 に書かれている。

ホストルートを積み上げずに重複を直す

一つのアドレスに対するホストルートは重複を直したように見えて、同じ範囲の二つ目のアドレスが必要になった瞬間に破綻する。そんなルートが二十も増えると、どのプレフィックスが正なのか誰にも言えなくなる。持続する解決は、アドレッシングの変更、重複範囲を避ける文書化されたトポロジー、あるいは一端での変換である。どれも一度きりの設計時間で済み、永遠の保守にはならない。

一時的なホストルートが本当に必要な場合は、後で外せるように理由、所有者、日付をそばに記録する。そのうえで正確なアドレスとサービス、さらに公共の宛先を試すのは、関係のないアプリケーションを静かにトンネルから外すローカルアクセスの変更が元の不具合より悪いからだ。ローカルプレフィックスと遠隔プレフィックスは別々に書き留めておくという習慣が、動くローカル ping を遠隔オフィスに届く証拠として回覧されるのを防ぐ。