Android OpenVPN：端末を root 化せずにプライベートルートを追加する

必要になるのは、プロファイルにまだ入っていないプライベートサブネットがもう一つ、たとえば 10.60.0.0/24 です。ノート PC ならルートを一本足して先に進めます。Android では VPN はアプリであり、tun デバイスはそのアプリのもので、root なしで編集できるルーティングテーブルはありません。ルートは必要ですが、行き先はクライアントが読み込むプロファイルの中であり、しかも相手側が同意しているときだけ機能します。ここでは編集、再接続、サーバー側、そして切り戻しを扱います。

編集の前に：ルートができることとできないこと

ルートが答える問いは一つです。この宛先の通信をどのインターフェースに載せるか。ルートは何も許可しません。ネットワークの所有者が、この端末からそのサブネットへ到達することを認めていなければ、正しいルートは正しく見える設定とゲートウェイでの静かな破棄を生み、次の一時間は間違ったファイルを編集して過ごすことになります。

まずその同意を得てください。ネットワークに所有者がいるなら書面で。そのうえで、自分がやらないことを書き留めます。端末にその LAN 内のアドレスを割り当てるのではなく、サーバーのリスナーを変えるのでもなく、ホスト名でサイトを選ぶのでもありません。これは四つの別の変更であり、あなたの担当は最初の一つだけです。

クライアントが実際に読み込むプロファイルを編集する

通常の OpenVPN オプション記述を取り込む互換クライアントなら、追加は一行です。

route 10.60.0.0 255.255.255.0

プロファイル本体の、ほかのルーティング指示の近くに追加し、operator の endpoint、証明書、鍵の扱い、検証行は元のままにします。一行借りるために古い例を丸ごと貼り付けないでください。圧縮、絶対パス、廃止された cipher 設定が一緒に付いてきて、別途デバッグの時間を取られます。

見落とされがちなのはファイルの所有権です。アプリがプロファイルを取り込んだ場合、アプリが使う複製はアプリのものであり、ダウンロードした元ファイルを編集しても何も変わりません。クライアントが対応するエディタを使うか、更新の経路で編集済みファイルを再取り込みし、似た名前が複数あるときは有効なプロファイル名を確認します。どれを変えたかを記録してください。

プロファイルにすでに route-nopull がある場合、サーバーからのルートは一つも入らず、端末が必要とする前置はすべて明示する必要があります。これは正当な設計ですが、一行の記載漏れがサーバーによる拒否とまったく同じに見えるという意味でもあります。

再接続して端末で確認する

まず切断し、アプリに前回のセッションを復元させるのではなく、編集したそのプロファイルに再接続します。接続ログを開き、クライアントが新しい行を解釈したことを確認します。画面側が無視するルート指示は、間違った複製を編集したときのよくある結果です。

宛先は名前ではなくアドレスで試します。既知のサービスポートへの TCP 確認は ping より多くの情報を与えます。多くのホストは ICMP に応答しつつ、サービスポートは絞られているからです。アドレスは応答し名前が応答しないなら、それはルーティングではなくリゾルバーの問題であり、次の節はあなた向けではありません。

ここには二つの範囲確認も属します。アプリ単位の VPN では、テストに使うアプリが対象集合の外にあるのにアドレスのルートだけが存在することがあるため、実際に対象内のアプリで試してください。また IPv4 の前置は IPv6 の経路について何も語りません。サービスが dual-stack なら、対応する IPv6 ルートを追加するか、意図しない経路をクライアントが選ぶことを想定してください。

否定的な結果の一つは早めに認識する価値があります。full-tunnel のルートがすでに 0.0.0.0/0 を覆っているなら、前置が欠けているわけではなく、追加し直しても何も変わりません。重複した網羅はサーバー側の拒否も欠けた応答も直しません。

サーバー側で経路を完成させる

端末の外で三つのことが真である必要があります。ゲートウェイには宛先へのルートと、端末の送信元をそちらへ転送する許可が要ります。宛先はその送信元を受け入れ、応答をゲートウェイ経由で返す必要があり、そうでなければ設計として出口での意識的な変換が要ります。OpenVPN マニュアルの route オプションが扱うのはクライアント側の指示であり、転送と戻り経路は別のマシン上の別の設定です。

宛先がゲートウェイの直後ではなく別の VPN クライアントの背後にある場合、サーバーにはそのピアのサブネットに対する iroute が必要です。この指示はサーバーが持つもので、どのクライアントが前置を所有するかを表します。端末は自分のプロファイルからそれを渡せませんし、クライアント側の編集をどれだけ重ねても代わりになりません。

戻り経路を明示的に確認してください。トンネルではなくデフォルトルートから出ていく応答は、典型的な半開きの症状を生みます。接続は一方向に成立し、何も戻ってきません。宛先が戻り経路を持てない場合、ゲートウェイでの送信元変換は正当な修正ですが、独自の影響を伴う方針判断です。

切り戻しと受け入れ

編集する前に以前のプロファイルを保存します。変更で状況が悪化したら、同じ再取り込みの経路でその複製を戻し、再接続し、以前の挙動が戻ることを確認します。これで、変えたつもりの箇所が実際に変わったと確認できます。元の状態に戻らない切り戻しは、アプリが見つけていない三つ目の複製を保持しているという意味です。

四つの条件が満たされたら変更を受け入れます。新しく再接続したあと、この順に試します。宛先がサービスポートで応答する、想定されていればプライベート名が解決する、HTTPS が意図したホスト名を依然として検証する、再起動や Wi-Fi から携帯回線への切り替え後も全体が動作する。最後の確認が、Android がトンネルを張り直すまでしか存在しないルートを捕まえます。

• 何かを編集する前に、ネットワークの所有者が宛先を許可していることを確認する。
• クライアントが読み込むプロファイルにルートを置き、再取り込みしてから再接続する。
• 正しいアドレスファミリーについて、アプリ単位の範囲の内側でサービスポートにより確認する。
• 転送、戻り経路、iroute はサーバー側で直す。端末側ではない。
• 切り戻し用の複製を残し、再起動後に再試験する。