Linuxルーターとバイパスルーターの導入概要：カーネル直動作で制御できる範囲

まず「カーネル直動作」で何を制御するのか整理する

ここでいう「カーネル」は、ユーザー空間で動作するV2RayまたはXrayのプロキシコアを指し、プロキシ機能をLinuxカーネルに組み込むという意味ではありません。プロキシコアは入 inboundポートに送られた接続を受け取り、ルーティングルールに従ってダイレクト接続、ブロック、リモートへのアウトバウンドを選択します。一方、NIC、アドレス、ルーティングテーブル、コネクショントラッキング、転送、ファイアウォールは引き続きLinuxが担当します。

そのため、プログラムに「実行中」と表示されても、プロセスが起動したことを示すだけで、LAN内の通信が必ず通過するとは限りません。ゲートウェイとして制御するには、パケットがまずLinuxホストへ到達し、nftablesまたはiptablesによって対象通信が透過プロキシの入口へ送られる必要があります。戻りの通信も予測可能な経路で元の端末へ戻らなければ、接続直後に切断されたり、一部のサイトだけ開いて他のアプリがタイムアウトしたりします。

ゲートウェイ、DNS、転送、プロキシコアの役割

デフォルトゲートウェイが答えるのは「パケットの次の宛先はどこか」です。DNSは「ドメイン名をどのアドレスに解決するか」を返します。Linuxの転送機能は、あるインターフェースから入ったパケットを別のインターフェースから出せるようにします。プロキシコアは、自身のインバウンドへ実際に送られた接続だけを処理します。4つは連携しますが、どれか1つが正常でも、残り3つの導入成功を証明することはできません。

たとえば、端末がLinux上のDNSサービスから正しいアドレスを取得できても、パケットは元のルーターへ送られることがあります。デフォルトゲートウェイをLinuxに変更しても、IPv4転送が有効でなければ、LAN外のアドレスへ接続できません。また、転送と透過入口が正常でも、ファイアウォールでゲートウェイ自身、LANセグメント、リモートサーバーのアドレスを除外していないと、ループが発生します。

メインルーターとバイパスルーターの通信経路の違い

メインルーターモードでは、Linuxは通常LAN側インターフェースと上流側インターフェースを同時に持ち、端末はDHCPでLinuxをデフォルトゲートウェイとして取得します。パケットはLAN側から入り、ルーティング判断、ファイアウォール、プロキシルールを経て上流側から出ます。経路を一元化しやすい反面、DHCP、NAT、転送のどこか1つにミスがあるだけで、ネットワーク全体が外部接続を失う可能性があります。

バイパスルーターモードでは、元のルーターがインターネット接続とアドレス配布を担当し、Linuxホストは同じLAN内に置かれます。デフォルトゲートウェイを明示的にバイパスルーターへ向けた端末だけがLinuxを通過します。DNSだけをバイパスルーターに変更し、ゲートウェイを元のルーターのままにすると、通常はDNSクエリしか確認できず、後続の接続は見えません。そのため透過プロキシのルールも一致しません。

戻り経路も確認が必要です。バイパスルーターが元のルーターへパケットを転送した後、元のルーターは応答を端末へ返す経路を把握していなければなりません。一般的には、バイパスルーターの出口で送信元アドレス変換を行うか、元のルーターにテスト用サブネットへの静的ルートを追加します。前者は簡単ですが、元のルーターからはバイパスルーターのアドレスに見えます。後者は送信元アドレスを保持できますが、ネットワーク機器に明確なルーティング設定が必要です。

• メインルーターの経路：端末 → Linuxデフォルトゲートウェイ → 透過プロキシまたはダイレクト接続ルール → 上流ネットワーク。
• バイパスルーターの経路：テスト端末 → Linuxバイパスルーター → 元のルーター → 上流ネットワーク。
• DNSだけを変更：端末 → Linuxでドメインを解決し、実際の接続は元のルーターへ直接送られる可能性があります。
• 明示的プロキシの経路：端末アプリ → Linux HTTP/SOCKS入口 → プロキシコアのアウトバウンド。透過ルールには依存しません。

復旧しやすい順序で導入する

導入時は「ノードが利用できるか」と「ゲートウェイが通信を制御しているか」を分けてテストします。まず明示的プロキシでコア設定とリモート接続を確認し、その後にLinuxの転送と透過ルールを有効にします。問題が起きても、プロキシのアウトバウンドかローカルネットワーク経路かをすぐに切り分けられます。

1. 元のネットワークを記録する

   テスト端末の元のIP、サブネットマスク、デフォルトゲートウェイ、DNSを保存します。バイパスルーターのLANアドレスも固定し、DHCPリースの変更で管理経路を失わないようにします。

2. コアのアウトバウンドを確認する

   まずV2RayまたはXrayでテスト専用のHTTP/SOCKSポート（例：10808）をリッスンし、1つのアプリだけでそのアドレスを明示指定します。この段階では透過転送を有効にしません。

3. コアの種類を確認する

   Windowsのテスト端末で同じノード設定を検証する場合は、v2rayNの「設定」→「パラメータ設定」→「Coreタイプ」を開き、選択したコアがプロトコル設定と一致していることを確認します。

4. システム転送を有効にする

   net.ipv4.ip_forwardが1か確認し、FORWARDチェーンでテスト用サブネットの通過が許可されていることを確認します。まず通常のルーティングを維持し、透過ルールの追加を急がないでください。

5. 透過入口を接続する

   TProxy用にパケットマーク、ポリシールーティング、ローカルルーティングテーブルを設定し、対象のTCP/UDP通信を12345へ送ります。LAN、マルチキャスト、ブロードキャスト、ゲートウェイ自身、リモートサーバーのアドレスは除外します。

6. 範囲を段階的に広げる

   まず固定IPを1つだけテストし、その後に端末グループ単位で範囲を広げます。変更するのはゲートウェイ、DNS、ルールのいずれか1項目だけにし、透過ルールを無効化して通常の転送へ戻す操作経路を残します。

以下のコマンドは状態確認用であり、ファイアウォールルールを自動生成するものではありません。出力では、転送値、ポリシールール、ルーティングテーブル、リスニングポートが自身の設定と一致しているかを確認します。nftablesを使用している場合は、互換レイヤーの表示だけでなく、実際のルールセットを直接確認してください。

sysctl net.ipv4.ip_forward
ip rule show
ip route show table 100
nft list ruleset
ss -lntup | grep -E '(:53|:10808|:12345)'

TProxy、リダイレクト、TUNの選び方

透過プロキシの実装は1種類ではありません。TCPリダイレクトは理解しやすい一方、元の宛先情報やUDP処理能力は実装に左右されます。TProxyは宛先情報を保持したままTCPとUDPを受け取れるため、ドメイン、IP、トランスポート層を組み合わせたゲートウェイの振り分けに適しています。ただし、ファイアウォールマーク、ポリシールーティング、プロキシコアの透過インバウンド設定が必要で、トラブルシューティングの手順は増えます。

TUNでは、プロキシコアが仮想ネットワークインターフェースを作成し、ルーティング層から通信を受け取ります。ファイアウォールのリダイレクト処理を一部減らせますが、ルート、DNS、インターフェース権限、除外ルールは正しく設定する必要があります。デフォルトルートが誤ってTUNを再び指すと、リモートサーバーへの接続までプロキシ自身へ戻され、ループすることがあります。

導入初期にTProxyとTUNを同時に重ねることはおすすめしません。2つの制御経路が共存すると、同じ接続が二重処理され、ログには再接続が続くことしか現れず、どの段階でループしているか判断しにくくなります。まず1方式でTCP、UDP、DNSを動作させ、切り替えが本当に必要かを検討してください。

DNSとルーティングの振り分けを分けて検証する

ドメインベースの振り分けには、信頼できるドメイン情報の取得元が必要です。プロキシコアはインバウンドプロトコル、DNSの結果、通信の検出などからドメインを取得できますが、これらは常に同じ情報になるとは限りません。端末がすでにドメインをIPへ解決してから透過通信としてゲートウェイへ入る場合、コアに見えるのは宛先IPだけの可能性があり、ドメインルールだけでは一致しないことがあります。

DNSでは自己ループも避ける必要があります。たとえばLinux上のローカルDNSがクエリをプロキシコアへ転送し、コアの上流ドメインを解決するために同じローカルDNSを呼び出す設定だと、クエリが元の入口へ繰り返し戻ります。LAN向けリスニングアドレス、コア内部の問い合わせ、上流DNSへの経路を明確に分け、ログで1回の問い合わせに説明可能なリクエストとレスポンスだけが発生していることを確認してください。

• テスト端末でダイレクト接続を想定したドメインを1つ解決し、返されたアドレスと解決時間を記録します。
• プロキシ処理を想定したドメインを解決し、指定したDNS入口へリクエストが到達することを確認します。
• 宛先IPを直接指定して接続し、IPルールとドメインルールで結果が異なるか確認します。
• TCPとUDPを個別にテストし、ブラウザーでページが開くことだけを根拠に全プロトコルの正常動作と判断しないでください。
• IPv4とIPv6の経路を確認します。IPv4だけを制御している場合、IPv6も同じルールを通るとは限りません。

リソース使用量、受け入れ基準、復旧準備

ゲートウェイの負荷はアイドル時のメモリだけで判断できません。暗号化接続数、UDPセッション、ログレベル、DNSキャッシュ、ルール規模がリソース使用量に影響します。ソフト割り込み、コアごとの使用率、NICスループットも確認してください。低消費電力の機器では、CPU全体の使用率が低く見えても、1コアがボトルネックになっている場合があります。

基準値の測定環境の例は、4コアのN5105、メモリ4 GB、Linux 6.1、ギガビット有線インターフェースです。1台の端末で500 Mbpsの連続転送を行い、約800接続を維持しました。透過プロキシ稼働後、プロキシコアの常駐メモリは約118 MB、マシン全体のCPU使用率は18%〜27%で推移しました。この結果は記録方法を示すためのもので、プロトコル、暗号化方式、ルール数、ハードウェアによって数値は変わります。

受け入れ確認では、少なくともダイレクト接続、明示的プロキシ、透過プロキシの3パターンを記録し、初回の名前解決時間、持続スループット、接続確立、UDP、ルール一致を個別にテストします。透過プロキシが明示的プロキシより明らかに遅い場合は、プロトコル名を変更する前に、MTU、二重制御、DNS待ち、単一コアのボトルネックを確認します。

1. 有効化前のルーティングテーブル、ファイアウォールルール、DNS設定、システム転送値をバックアップします。
2. 透過ルールとポリシールートを同時に撤回できるコマンドまたはサービス操作を用意します。
3. 元のメインルーターのDHCP設定を残し、バイパスルーターの試験運用中にすぐ削除しないでください。
4. ログローテーションを設定し、デバッグログでディスクを使い切らないようにします。
5. Linuxホストを再起動して再検証し、ネットワークインターフェースの準備より前にルールが読み込まれないことを確認します。

導入前の最終判断

少数のアプリだけでプロキシを使うなら、明示的プロキシのほうが状態を確認しやすく、LAN全体の経路を変更する必要もありません。テレビ、端末ツール、個別にプロキシを設定しにくい機器まで制御したい場合はゲートウェイ方式に価値がありますが、ルーティング、DNS、ファイアウォール、プロキシコアを同時に管理する必要があります。

初回導入は、バイパスルーターと1台のテスト端末から始めるのが適しています。まず10808の明示的プロキシを確認し、次にシステム転送を有効化し、最後に透過入口を12345へ接続します。ルール一致、DNS経路、TCP、UDP、IPv4、復旧操作を確認してから、DHCPを移行するかLinuxをメインルーターにします。

• 端末、Linux、元のルーター、上流ネットワーク間の往路と復路を明確に図示できる。
• ポート53、10808、12345をそれぞれどのプロセスがリッスンしているか説明できる。
• プロキシコアを停止する前に、通信を誘導するルールを撤回できる。
• ログ、ポート、ルーティングテーブル、ルールカウンターを照合して障害箇所を判断できる。
• プロキシ経路に依存せずLinuxの管理画面へアクセスできる。