はじめに（この記事で分かること）#

VPNルーターが制御するのは、対象ネットワークからの通信をVPN経由にする部分である。Tor経由にする部分はQubes側の役割であり、対象はsys-whonixを経由するように設定したWhonixワークステーションに限られる。ルーターを置くだけで、すべてのVMや家庭内端末がTorを使うわけではない。OPNsenseの経路制御とQubes-Whonixの構成は、この2つの役割を分けて読む必要がある。

以下は公式wikiと公式手順に基づく構成の解説であり、実機での動作検証を報告するものではない。

前提: 脅威モデルの整理#

想定するのは、回線上にTorへの直接接続を出さないことや、Torへの接続制限を回避することを目的とする構成である。脅威モデル入門で扱う観測者のうち、まずISPから何が見えるかを考える。ただし、接続先IPをVPNサーバーに変えることと、通信解析からTor利用を隠し切ることは同じではない。Whonixのトンネル併用の解説も、VPNを足せば匿名性が高まるとはしていない。

構成図とQubes-Whonixの経路#

図の矢印は上流から下流への接続関係である。ワークステーションから外へ出る通信は逆向きにたどる。

物理構成
[ISP] → [ルータ] → [VPNルータ: OPNsense/pfSenseでWireGuard終端]
                        ↓
                    [対象LAN] → [Qubes OS]

Qubes内（VPNは物理ルーターで終端）
sys-net → sys-firewall → sys-whonix → Whonix-Workstation

比較: VPNをQubes内で終端する別案
sys-net → sys-firewall → sys-vpn → sys-whonix → Whonix-Workstation

Qubes OSは、同一ハードウェア上のVMを用途ごとに論理的に分離し、侵害の波及を抑える設計である。日常用・仕事用・匿名用を分ける意味はここにある。物理的に別の端末へ分ける方式とは異なり、分離の安全性はXenハイパーバイザーにも依存する。Qubes OSのFAQは、ハイパーバイザーが突破された場合にはシステム全体へ影響しうると説明している。

Qubes-Whonixでは、Torゲートウェイのsys-whonixと、アプリケーションを動かすWhonix-Workstationを分ける。Tor経由にするワークステーションはNetVMをsys-whonixに設定する。sys-firewallなどを直接NetVMにした通常のVMや、同じLANにある家族・IoTの端末には、このTor経路は適用されない。

Whonix wikiのVPN before Tor手順には、Qubes内に独立したVPNゲートウェイを置く方法がある。外向きのVM接続関係はWhonix-Workstation → sys-whonix → sys-vpn → sys-firewall → sys-netであり、外部サービスを通る順序は利用者 → VPN → Tor → 宛先となる。物理VPNルーターで終端する構成ではsys-vpnは必須ではない。図の別案を加えるならVPNがもう1段増えるため、分離したい役割を先に決める必要がある。なお、このwikiのVPNクライアント設定例はOpenVPNを前提とし、ルーターのWireGuard設定手順とは区別する。

VPNルーターでWireGuardを終端する条件#

OPNsenseとpfSenseには、外部VPNサービスへWireGuardで接続する公式手順がある。ルーター上にトンネルを作っただけでは、対象LANの通信すべてがそこへ送られるとは限らない。OPNsenseの選択的ルーティング手順は、対象ホストを指定するポリシールーティング、NAT、VPN停止時の迂回防止を分けて扱う。pfSenseのVPNクライアント構成例でも、トンネル設定に加えてLAN側のポリシールーティングとDNS設定を行う。

VPN経由を必須にしたい場合は、次の4点を確認する。OPNsenseの手順にあるキルスイッチは任意の追加設定であり、トンネル作成だけで有効になるものではない。

  • 対象ネットワーク: Qubesを接続するLAN・VLAN・送信元アドレスを明示し、その対象からの外向き通信をVPNゲートウェイへ送る。
  • トンネル停止時: VPNが使えなくなったとき、通常のWANへ迂回せず対象通信を遮断する。ルールの設定に加え、実際にトンネルを停止した状態で確かめる。
  • IPv6: VPN内に通すならIPv6用の経路と遮断ルールも揃える。扱わない場合は対象ネットワークからIPv6で直接外へ出ないようにする。
  • DNS: 対象端末だけでなく、ローカルDNSサーバーが上流へ出す問い合わせの経路も確認する。端末をVPNへ向けても、ルーターのDNS問い合わせだけが通常のWANへ出る場合がある。

これらはOPNsense公式手順のキルスイッチ・IPv6・DNSの注意事項に基づく確認項目である。未確認の構成をVPN経由に強制できているとは扱わない。

Mullvadのルーター向け手順では、WireGuard設定ファイルの生成・ダウンロードと対応ルーターへの取り込みが案内されている。設定値を用意する手段にはなるが、対象ネットワークの経路や停止時の遮断まで自動で保証するものではない。

VPNをTorの手前に置く構成では、UDPを使うWireGuardでTorを運ぶことにプロトコル上の問題はない。Whonix wikiは、TCP・UDPのどちらのVPN接続も動作し、Tor自身がUDPを運べなくても、この順序では運ぶ必要がないと説明している。TCPの制約は、VPNをTorの後ろに置く逆の利用者 → Tor → VPN → 宛先構成の話である。Tor before VPNの手順にあるproto tcpは、その構成で使うOpenVPNの設定であり、WireGuardに追加する設定ではない。

検閲環境でTor over VPNが意味を持つ条件#

Torへの直接接続や、利用できるブリッジへの接続が妨げられていても、VPNへの接続が通り、そのVPNの先からTorへ到達できる環境なら、Tor over VPNが接続を確保する手段になりうる。これはVPN before Torの接続順序から整理できる適用条件であり、匿名性を高めるための一律の推奨ではない。利用するVPNへの接続も遮断されるなら、この経路は成立しない。Mullvadもルーターでは難読化を提供しておらず、接続できない検閲環境があると明記している。

ブリッジはTorへ入るための代替の入口である。Tor Projectのブリッジ案内からたどれる検閲回避手段の説明では、obfs4は通信をランダムに見せ、WebTunnelはHTTPSのWebアクセスに見せ、Snowflakeはボランティアのプロキシを経由する方式として説明されている。VPNがTorの手前に別の通信経路を置くのに対し、これらはTorへの入口や通信の見え方を変えて接続を助ける。

ブリッジで接続できるなら、接続の確保という目的だけでVPNを追加する必要はない。ブリッジとVPNのどちらが使えるかは環境に依存するため、特定の方式が常に遮断を越えられるとはいえない。

VPNとISPのどちらを信頼するか#

信頼先の比較では、誰が何を観測できるかを分ける必要がある。ISPは回線からの接続先IPなどを観測しうるが、それだけで家庭内の個々の端末を常に識別できるとは限らない。Torへ直接接続すれば接続先はTorの入口となり、VPN経由に限定できていれば回線上の接続先はVPNサーバーとなる。一方、VPN事業者は接続元IPと、その先のTor入口への接続を観測しうる。VPNがTor経由の最終的な閲覧先までそのまま知る、という構成ではない。これはWhonixが示す接続順序に沿った観測範囲の整理である。

VPNへの匿名決済も、実名との結び付きを断つ保証にはならない。Whonixのトンネル併用の解説は、VPNへ自分のIPから接続する限り、決済方法を変えてもそのIPは事業者に知られうると指摘する。ISPにTor入口への直接接続を見せない利益と、VPN事業者を新たな観測者として加える負担のどちらを重く見るかは、脅威モデルによる。

Qubes OSのハード要件#

2026年11月2日に確認したQubes OSの公式要件では、最小要件と推奨要件は次のように分かれている。

項目最小推奨
メモリー6GB RAM16GB RAM
ストレージ空き容量32GB128GB。高速SSDを強く推奨
CPU・仮想化64bitのIntelまたはAMD。Intel VT-x with EPTとVT-d、またはAMD-V with RVIとAMD-Vi64bitのIntel。Intel VT-x with EPTとVT-d。マイクロコード更新が続いているCPU

これはメモリー・ストレージ・仮想化機能の要点であり、対応機種を保証する一覧ではない。公式資料も、要件を満たすことは必要条件であって動作の十分条件ではないとしている。導入前に同ページのハードウェア選定情報と機種ごとの互換性を確認する。

限界と残るリスク#

運用上は、VPNルーターの経路・遮断設定とQubes側のNetVM設定の両方が前提となる。通常のVMを誤って使うことまで、VPNルーターが防いでくれるわけではない。Qubesの論理的な分離にもハイパーバイザーへの依存が残るため、侵害が他のVMへ絶対に波及しないとはいえない。

VPN事業者からTor入口への接続を隠すことは、この構成の目的ではない。また、ISPや広い範囲を観測する相手による通信解析を防ぐ保証もない。Whonixの注意事項が指摘するように、トンネルを追加するほど設定は複雑になり、その追加が安全性の向上につながるとは限らない。

まとめ#

ISPへTor入口への直接接続を出さないことが目的なら、対象LANの範囲を確定し、VPN停止時の遮断、IPv6、DNSを順に確認する。Tor経由にするワークステーションについては、NetVMがsys-whonixであることも別に確認する。VPNに接続できたという結果だけでは、この2つの確認は済まない。

検閲回避が目的なら、まずTorへの直接接続・ブリッジ・VPNのどこで接続が妨げられているかを切り分ける。VPNへの接続と、その先のTorへの到達性が残っている場合に限り、Tor over VPNを候補として扱う。追加する経路の役割を説明でき、停止時の挙動まで確認できることが、この構成を運用する条件である。

出典#