バイパスゲートウェイで解決したいこと
家庭や小規模オフィスで「既存の Wi‑Fi ルータはそのまま」「外向きの出口だけを柔軟にしたい」とき、小型 Linux（NUC・安価な x86 ボックス・余っているラズパイ等）を LAN にぶら下げ、端末の既定ゲートウェイだけをそこへ向ける構成がよく使われます。OpenWrt を焼き直す負担を避けたい読者には、OpenWrt＋OpenClash の統合記事とは別軸の再現手順になります。
ゲートウェイ Linux 上で Clash Meta（Mihomo）の TUN を有効にすると、本機発のトラフィックを仮想インターフェース側へ載せやすくなります。一方、LAN から転送（forward）されてきたパケットは、カーネルのルーティングと nftables の方針が曖昧だと「ゲートウェイには届くのに戻りが途切れる」「二重 NAT で挙動が読めない」などに陥りがちです。概念の土台は TUN モード解説 を先に押さえ、本稿では nftables＋転送＋NAT を明示したうえで Clash 側の設定と突き合わせます。サービス化や権限の細部は Ubuntu＋systemd の TUN 手順 に任せ、ここではネットワーク平面に集中します。
どの GUI／コア配布を使うかは環境差が大きいので、選定の観点だけ クライアントの選び方 に譲ります。以下は mihomo 系の YAML を想定した断片です。
トポロジとアドレス設計
典型例として、主ルータが 192.168.1.1/24、バイパス Linux が 192.168.1.2/24、クライアントが 192.168.1.0/24 にいる想定で説明します。Linux は同一 L2 セグメント上の別 IPとして振る舞い、クライアントのデフォルトルートだけ 192.168.1.2 にします。主ルータ側の DHCP で「特定端末だけ GW を 1.2」へ変える運用が一般的です。
外向きの最終出口は依然として主ルータ経由になることが多く、バイパス Linux から主ルータへは MASQUERADE（または SNAT） で送信元をそろえないと、戻りパケットがクライアントへ届かないケースがあります。nft の詰め方は後述します。
nft -f ロールバックなど、手元で戻せる手段を先に用意してください。
カーネル転送（ip_forward）
Linux をゲートウェイとして使う前提は IPv4 転送が有効であることです。恒久化は /etc/sysctl.d/*.conf などに net.ipv4.ip_forward=1 を書き、sysctl --system で反映します。IPv6 を触る場合は net.ipv6.conf.all.forwarding も別途検討が必要ですが、本稿では IPv4 に限定します。
反映確認は sysctl net.ipv4.ip_forward が 1 であること、および cat /proc/sys/net/ipv4/ip_forward が一致することです。ここが 0 のままだと、nft で許可していても転送されません。
nftables：FORWARD の許可と NAT
ディストリビューション既定の firewalld 等と競合しないよう、検証用マシンでは一旦シンプルなテーブルから始めるのが安全です。以下は読み替え必須のプレースホルダです。LAN_IF はクライアント側（例：enp2s0）、WAN_IF は主ルータ方向（同一ブリッジ上なら実質同じ IF のこともありますが、論理として「外向きを出す口」）に置き換えてください。
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
# tighten for production
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname "LAN_IF" oifname "WAN_IF" accept
iifname "WAN_IF" oifname "LAN_IF" ct state established,related accept
}
}
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifname "WAN_IF" masquerade
}
}
実機では iifname / oifname を ip -br link の出力と突き合わせます。ブリッジを挟む構成なら、転送がブリッジインターフェース基準になる点に注意してください。nft の保存先（/etc/nftables.conf など）はディストリビューションに従います。
ここまでで「クライアント → バイパス Linux → 主ルータ → インターネット」のL3 転送と NATが成立します。次に Clash がどのレイヤでトラフィックを握るかを決めます。
クライアント側：既定 GW と DHCP
手動設定なら OS のネットワーク設定で「ルータ（ゲートウェイ）」をバイパス Linux の IP にします。DHCP なら、主ルータまたは別の dnsmasq でホスト単位のルータオプションを上書きする方法が扱いやすいです。DNS も同じホスト（バイパス Linux 上の Clash リスナー、あるいは 53 を転送）に揃えると、名前解決と実経路のズレが減ります。
fake-ip 系の設定では LAN から見える応答アドレスと実ルートの関係が分かりづらくなるため、宅内トラフィックで困ったら fake-ip と LAN ルータの切り分け を参照してください。
Clash：TUN・LAN 公開・DNS の整合
ゲートウェイ用途では allow-lan: true と、外部コントローラを開く場合のバインド先が論点になります。具体例は LAN 共有と bind-address／サブネット を併読してください。TUN ブロックはコアのバージョンに合わせて stack や auto-route を選びますが、転送パケットをどこまで Clash が握るかはコアとルール設計次第です。ローカル発と転送発で経路が分かれる場合は、redir-port / TPROXY 系と併用する構成も現場では選ばれます。本稿では再現性の核となる nft と TUN の両立を優先して記述します。
allow-lan: true
bind-address: "*"
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
DNS の nameserver／fallback／fake-ip の組み合わせは、ゲートウェイほど全体挙動に効きます。Mihomo DNS の実践手順 でパラメータを揃え、ルール側は ルール分流のベストプラクティス と矛盾がないかを確認してください。
検証コマンドと期待値
バイパス Linux 上で ip -br addr、ip route、ip rule、ss -lntup | grep mihomo（例）を確認します。クライアントからは ping 192.168.1.2、続けて ping 1.1.1.1 と DNS 名の両方を試し、Clash ログでポリシーが想定どおりかを見ます。nft は nft list ruleset でカウンタが増えるかを追うと切り分けが速いです。
外向きが通った直後にだけ失敗する場合は、購読やノード側の話に寄ることがあります。購読とノード管理 もセットで見直してください。
典型の落とし穴
TUN を切ったあとにルートが残り「突然ネットに出られない」症状は、デスクトップでもゲートウェイでも起こり得ます。復旧の考え方は プロキシ／TUN 残りの記事 が参考になります。また、バイパス構成は二重 NATになりやすく、P2P やポート開放が期待とズレる点も押さえておくとよいでしょう。
まとめ
小型 Linux をバイパスゲートウェイに据える流れは、(1) アドレスとデフォルトルート、(2) ip_forward、(3) nftables の forward と MASQUERADE、(4) Clash TUN と DNS／LAN 公開の整合、の順に積み上げると再現しやすいです。OpenWrt 一括構成と比べて自由度は高い反面、責任範囲も自分側に寄ります。上流 OSS の追跡は GitHub で行いつつ、日々の入手と導線はサイトのダウンロードページを主にすると運用が安定します。
→ Clash を無料ダウンロードし、ルール編集とログの見やすさからゲートウェイ運用の負担を下げてみてください。バイパス Linux で詰めた設定は、デスクトップクライアントとも同じ考え方で引き継げます。