Android VPN サーバー：root 権限だけではスマホに到達できない

root 権限が変えるのは、プロセスが試せるネットワーク操作の範囲です。スマホに公開到達可能なアドレスを与えるわけでも、キャリア側の受信マッピングを確保するわけでも、再起動後もデーモンを生かし続けるわけでもありません。Android スマホを VPN サーバーにできるか判断するときは、三つの問いを分けてください。想定したクライアントはそもそもリスナーに届くのか、サーバーの実装にはどの権限モデルが必要か、そしてトンネルが上がった後に何を転送するのか、です。

誰が、どこからスマホに到達する必要があるのか

同じ許可された LAN 上のクライアントと、モバイルデータ上のクライアントは、別々のネットワークを試していることになります。どちらを想定するかを先に決めてください。答えは互いに流用できません。Wi-Fi では、求めていない受信トラフィックには通常、上流ルーターでのマッピングと、その先の使える公開経路が必要です。セルラーではキャリアグレード NAT のため、スマホ側が何を許しても受信 IPv4 は使えないことがよくあります。

root が触れられないのは、まさにこの最後の点です。スマホのローカルファイアウォールとキャリアの NAT は別のシステムであり、前者を変えても後者には影響しません。プライベートなインターフェースアドレス、モバイルデータのアイコン、待ち受けているソケットは、到達可能性の証拠にはなりません。キャリア経路がグローバルにルーティング可能な IPv6 を提供していたとしても、それには意図的なリスナーとファイアウォールのポリシーが別途必要です。アドレスを持っていることと、接続を受け入れることは同じではありません。

提供と転送は、二つの別の成功です

VPN のハンドシェイクが完了したことは、トンネルが存在する証拠です。スマホの背後の LAN にクライアントが届くことや、スマホがインターネットの出口になれることは証明しません。それらは、内部のアドレス設計、ルート、戻り方向の挙動、そして実際にやりたい作業に合わせた狭い転送ポリシーの上に築かれる、別々の設定です。

失敗の形は予測できます。ハンドシェイクは成功し、クライアントは接続済みと表示され、何も読み込まれないという状態です。クライアントをデバッグする前に、二つの役割のどちらを作っているのかを決めてください。スマホのネットワーク上の機器へのリモートアクセスと、フルトンネルによるインターネット出口では、必要な転送ルールが異なります。一つだけ欲しかったのに両方を許すと、求めた能力を増やさないまま露出だけが広がります。

権限モデルは選択であり、root かゼロかではありません

カーネルの TUN デバイスを使う従来型の OpenVPN デーモンには、対応するケーパビリティ、デバイスノードへのアクセス、そして Android のセキュリティポリシーの協力が必要です。root は SELinux からの包括的な免除ではありません。特権プロセスであってもプラットフォームのポリシーに縛られます。Linux サーバーでは快調に動くバイナリが、スマホでは権限に関するはっきりしたエラーも出さずに失敗するのはそのためです。

ユーザー空間のゲートウェイ実装では、権限モデルがまったく別になり得ます。ですから、Android の VPN サーバーはすべて root が必要という一般的な主張は広すぎます。root が買ってくれるのは、より多くの操作を試せる能力であって、それが許可される保証でも、結果に到達できる保証でもありません。

Android 自身の VPN サービス登録は、また別の仕組みです。アプリに、定義されたライフサイクルを持つ管理されたクライアントインターフェースを与えます。汎用的なサーバーインストーラーではなく、端末からデーモンを起動しても、常時稼働の管理、アプリごとのポリシー、自前の復旧経路は得られません。

出口が欲しいなら、アーキテクチャを変える

既存の OpenVPN プロファイルとの互換性ではなく、スマホ経由の遠隔インターネット出口が目的なら、オーバーレイ網のサポートされた出口ノードのほうが設計として適しています。Tailscale は、登録、認可、クライアント選択の手順を含むAndroid の出口ノードの役割を文書化しています。

このトレードオフは現実的で、はっきり言う価値があります。別のプロトコル、別の信頼モデル、そしてそのアカウントと調整サービスへの依存を受け入れることになります。変更していない OpenVPN クライアントがオーバーレイに加わるわけでも、公開アドレス上に OpenVPN リスナーができるわけでもありません。

配備にまだ必要なもの

どの経路を選んでも、運用の基本が一週間もつかどうかを決めます。サーバーの資格情報は非公開にし、クライアントの識別情報は別々に発行し、失効は必要になる前に計画してください。更新がどう届くか、何がサービスをバックグラウンドで動かし続けるか、再起動やネットワーク変更の後にどう復帰するかを決めます。

便利に見える近道は避けてください。時代遅れの静的バイナリ、ハードコードされたインターフェース名、既存のファイアウォールポリシーを消す起動スクリプトです。そのうえで、結果は具体的なテストでのみ受け入れてください。許可された遠隔クライアントが目的のリソースに届くこと、禁止された宛先は使えないままであること、サポートされたライフサイクルイベントの後に機器が自力で戻ること。root 権限はその結果の一つの材料になり得ますが、決め手になることはまれです。