USB経由のAndroid逆テザリング：コマンド、確認、ロールバック

逆テザリングはスマートフォンの通信をコンピューターへ移し、そのコンピューターの接続から外へ出します。USBケーブルだけでは実現しません：スマートフォンには経路制御を引き受けるキャプチャサービスが、コンピューターにはそのパケットを先へ運ぶリレーが必要です。経路には四つのホップがあり、アプリケーション、スマートフォンでのキャプチャ、USBリレー、ホストの出口で、それぞれ担当が異なります。この手順書はその経路を組み、ホストのVPNをあるべき位置に置き、結果を信頼する前に各ホップを確認します。

何かを実行する前にホップを把握する

各ホップはそれぞれのポリシーを適用するため、片端で動作しても他方については何も言えません。アプリケーションは宛先とリゾルバーを選び、キャプチャサービスはどの通信をリレーに入れるかを決め、リレーはホストのソケットへ転送し、ホストの経路制御とVPNが宛先が最終的に見るアドレスを決めます。

スマートフォンのキャプチャ役を同時に持てるVPNサービス利用者は一つだけなので、二つ目の通常のVPNアプリがリレーの上に重なることはありません。VPNがコンピューター側にあるなら、キャプチャサービスはそのコンピューターへの入口であり、遠隔トンネルがすでに結果を守っている証拠ではありません。

スマートフォンに触れる前にリレーを用意する

Gnirehtet はこの構成の文書化された例で、ルート権限なしのVPNサービスクライアントをスマートフォンに置き、ホスト側でADB経由のリレーを動かし、IPv4上のTCPとUDPを扱います。リポジトリはこのプロジェクトがもはや活発に保守されていないとも述べているため、参照設計および実験室向けの実用ツールとして扱い、管理された端末群で標準化するサポート製品とは考えないでください。

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

まずadb devicesを実行します。ホストのデバッグキーを受け入れていないスマートフォンは未承認として報告され、端末の確認が承認されるまでリレーは接続しません。gnirehtet runはクライアントを導入し、リレーを起動してキャプチャを有効にしますが、手順を分けた版では代わりに文書化されたinstall、relay、startのサブコマンドを使ってください。

ADBアクセスは端末の制御関係であり、ネットワーク設定ではありません。自分が管理するコンピューターだけを承認し、作業が終わったらその承認を取り消す計画を立ててください。

ホストのVPNを経路に戻す

リレーはホスト上の通常のプロセスなので、その先の接続はホストの経路表に従います。フルトンネルのプロファイルはそれを運びますが、分割トンネルでは運ばない場合があります。ホストのVPNがアプリ単位の制御を使う場合はリレーのバイナリを許可集合に加えないと、ブラウザーが保護されて見える間もリレーは物理インターフェースを使い続けます。

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

ホストのVPNに接続する前と後に、最初の二つのコマンドを実行します。アドレスが変わらなければ、クライアント画面が何を言おうとリレーはトンネル上にありません。私設のみのトンネルは公開の宛先を通常のホスト出口に残しますが、それは漏えいに見えても設定したポリシーどおりです。

リレーを通る通信のDNSはホスト側で解決されるため、どのサーバーが名前を見るかはホストのリゾルバーが決めます。スマートフォンのプライベートDNS設定はリレーを越えて引き継がれず、スマートフォン側のリゾルバー試験ではホストの問い合わせはわかりません。

各ホップを個別に確認する

三つの確認をこの順に行います：スマートフォンがリレーに到達すること、リレーがホストのポリシーの下で宛先に到達すること、アプリケーションが宛先を正しく解決して使うことです。ページを再読み込みして推測するのではなく、最初の失敗で止めてください。

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

接続性ダンプのVPNネットワーク項目 はキャプチャサービスが有効であることを示し、リレー自身のログはフローが届いているかを示します。どちらか一方に欠ければ問題はきれいに分かれます：キャプチャがなければスマートフォン側、フローがなければホスト側です。

ホストで動くブラウザーはホストのブラウザーの経路を証明するもので、リレープロセスの経路ではありません。それぞれが報告するアドレスを比べ、公開ページだけでなく私設リソースも試してください、なぜなら私設のみのトンネルは一方を通し、他方を通さないことがあるからです。

撤去し、障害時の挙動を選ぶ

ロールバックは手順書の一部です。リレーを停止して削除し、キャプチャクライアントを削除し、作業が終わったらスマートフォンの開発者向けオプションからホストのデバッグ承認を取り消します。

gnirehtet stop
gnirehtet uninstall
adb kill-server

リレーが消えたときにスマートフォンがどう振る舞うかを決めます。明示的に選ばないとモバイルデータへ戻り、経路に載せようとした通信が漏れることがあるため、接続ブロックの挙動やVPNポリシーを意図的に設定し、依存する前に撤去を試験してください。

承認したホスト、リレーの版、ホストのトンネルポリシー、撤去の手順を記録します。その記録があるからこそ、次の逆テザリング設定は再発見の午後ではなく再現可能な作業になります。