ルーター VPN で一台だけ通すにはトグルではなく三つのルールが要る

ルーター VPN にデバイス単位のスイッチはなく、探しているトグルはあなたの代わりにポリシールーティングのルールを書き込むショートカットです。一台のノート PC、一つのポート範囲、一つのアドレス一覧、あるいは一つの LAN セグメントだけがトンネルを使い、ほかはすべて WAN のままでなければならない瞬間、あなたは機能を有効にしているのではなくポリシールートを組み立てています。作業には三つの可動部分があり、それぞれ違う形で壊れます——ルートのないマーク付きテーブルは沈黙に見え、誤ったチェーンに当てたマークは何も起きていないように見え、欠けた NAT ルールは接続はするが何も運ばないトンネルに見えます。さらに二つの部品、DNS と IPv6 が、mangle ルールに決して現れないために抜け落ちます。

神話：トンネルはクライアントの設定である

ルーター側の VPN クライアントは、0.0.0.0/0 をメインのルーティングテーブルに入れてトンネルへ向けるという、乱暴だが一つのことをうまくやります。WireGuard はそれを AllowedIPs から導き、 OpenVPN はサーバーから押し出される redirect-gateway から導きます。どちらもルーター背後のすべてのホストの経路を変えます。AllowedIPs を狭めたり route-nopull を加えたりするとクライアントが入れる内容は変わりますが、誰に適用されるかは変わりません。クライアントはデバイスを見ず、見るのはパケットだけです。

送信元や宛先による選択はルーティングの判断であり、RouterOS では mangle ルールと二つ目のテーブル、OpenWrt や DD-WRT では MARK と ip rule、pfSense ではゲートウェイをトンネルにしたファイアウォールルールという形で、ルーターのポリシー層に属します。 Netgate の WireGuard クライアントのレシピ は、そのプラットフォームではルールのゲートウェイ、インターフェースの割り当て、外向き NAT のエントリがすべて一致して初めて一台のクライアントがトンネルを使えるため、当て推量の前に読むべきものです。

神話の残り半分は二台目のルーター。二台目の箱を買ったり、デバイスをゲスト SSID へ移したりするのは、しばしば実際に効きますが、その理由はハードウェアではなく、デバイスを独自のサブネットに置くことでファームウェアがすでに理解している送信元セレクタが手に入るからです。所有しているルーターでそのセグメントを定義できるなら、追加の箱はあなたが持っていない問題を解いているだけです。

その一：デフォルトルートではないトンネル

RouterOS では、デフォルトルートなしでクライアントを追加し、トンネルに専用のテーブルを与えます。最初のルートがマーク付きデフォルトで、二つ目が失敗側の半分です。

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

到達不能ルートがあるからこそ、マーク付きテーブルはメインテーブルの例外リストに勝ります。トンネルが落ちると、マークされたパケットは黙って WAN に戻るのではなく即座に到達不能を受け取るので、障害は一時間後に見る地理位置情報ページではなく、アプリケーションのエラーメッセージに現れます。

RouterOS 7 は 6.x が一つにまとめていたものを分割し、テーブルは /routing table add name=vpn fib で宣言したうえで、ルートと mangle ルールでは名前で参照します。テーブルを定義せずに routing-mark を直接書く 6.x のスニペットは、きれいに読み込まれて何にも一致しません。もう一つの定番は 0.0.0.0/1 の二つの半分、あるいは同じテーブル内の同じ距離の二つのデフォルトで、カーネルはどちらかを選び、再起動後に挙動が変わることがあります。

その二：ルート検索より前にマークする

どのパケットがそのテーブルに入るかをセレクタが決めます。RouterOS は通常、宛先ポリシーならアドレスリスト、デバイスポリシーなら送信元アドレスから始めます：

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux のファームウェアも、netfilter のマークと、マークされたパケットを用意したテーブルへ導くルールで同じことをします：

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

チェーンは好みの問題ではありません。パケットが FORWARD に届く時点でルート検索はすでに終わっているので、そこで MARK や DROP をしても書き換えるか捨てるしかできません。マークは転送トラフィックなら PREROUTING に、ルーター自身が発するトラフィックなら OUTPUT に入る必要があり、ルーターの DNS、NTP、更新確認はそこに住んでいます。この出力経路こそ、完全にトンネル化した構成がリークテストで依然として ISP のリゾルバから答える通常の理由です。

デバイスポリシーには、ずれない一致が必要です。DHCP でアドレスを予約するか、専用セグメントのインターフェースに一致させてください——後から別のデバイスへ移るアドレスは、黙って誤ったクライアントにトンネルを適用します。独自のサブネットを持つ SSID ごとのブリッジは同じ発想のより丈夫な版で、IPv6 のルールにも置き場所を与えます。

その三：NAT、DNS、そして LAN の例外

トンネルから出るトラフィックには、向こう側が答える送信元アドレスが必要です。変換の範囲をトンネルインターフェースに限定し、RouterOS なら out-interface=VPN_NAME、Linux なら -o tun0、pfSense なら一致する外向き NAT エントリを使います。その限定のない masquerade ルールは、放置したいトラフィックまで書き換え、症状はトンネルを通らないデバイスがパブリックアドレスを失うことです。

LAN の例外は、トンネル本体よりも多くのサポートスレッドを生みます。マーク付きテーブルがデフォルトルートだけを持つ場合、選択したデバイスからのプリンタや NAS 宛てはそのデフォルトに一致してトンネルへ消えます。同じテーブルに LAN ルートを足すか、セレクタでローカルサブネットを除外すればよく、どちらも効きますが、後から VLAN を足すときは除外のほうが正しく保ちやすいです。

DNS は別の経路を通ります。ルーターが転送するクエリはルーター発で OUTPUT に従い、転送マークには従わないので、完全にトンネル化したノート PC でも ISP 経由で名前解決できてしまいます。クライアントをトンネル経由で届くリゾルバに向けるか、ルーター自身のポート 53 のトラフィックにマークを付け、そのうえで解決後のアドレスを確認し、答えがウェブリクエストと一緒に旅したと決めつけないことです。

ルールは一致するのにアプリが依然 WAN を使うとき

宛先リストはすぐ古くなります。名前がリストにないアドレスへ解決されると、リクエストは WAN に出てしまい、リストのアドレスに対して行ったテストはすべて成功していたことになります。クライアントが使うのと同じリゾルバからリストを更新し、一台のデバイスから全トラフィックを本当に通したいなら送信元ベースのセレクタを選んでください。

IPv6 は静かな抜け道です。デバイスは独自のデフォルトルートと独自のルールセットを持つ第二のアドレスファミリーを持っており、IPv4 アドレスだけに一致させるのはポリシーの半分です。同じセレクタを ip6tables や nftables の相当物に適用するか、そのセグメントの IPv6 を事故ではなく意図的に無効にしてください。

確立済みの接続も重要です。変更前に作られた conntrack エントリは期限切れまで古い経路をたどり続けるので、編集中に開きっぱなしだったブラウザは、決して適用されなかったルールとまったく同じに見えます。ポリシーを判断する前に新しい接続を開くか、状態をフラッシュしてください。

二台のデバイスと再起動で検証する

トンネルに入るべきデバイスと入るべきでないデバイスを試し、速度の数字ではなく二番目のホップを比べます。それぞれの traceroute は二番目のホップにトンネルのゲートウェイか ISP のゲートウェイを示すので、両方が同じに見えるなら、マークかテーブルがルールの言うとおりに動いていません。テストには新しい接続を使ってください。

そして再起動します。起動順序は、動いていたポリシーが壊れる場所です——到達不能ルートが入る前にクライアントが上がっている必要があり、古いルールセットを復元する保存済みスナップショットはあなたのテーブルを上書きします。すべてのルールが保存された設定にあり、マーク付きデフォルトが起動後に存在することを、入力した直後だけでなく確認してください。

何かが失敗したら、まずマークを外して通常のトラフィックが戻るか見て、そのあとテーブルを外します。この順序で、ルーティングの問題を追っているのかファイアウォールの問題を追っているのかが分かり、作業を終える間も家庭には動くプリンタが残ります。