sshuttle と完全な VPN：その方式が実際に何をカバーするか
sshuttle が運べるのは転送方式が対応する範囲だけです。まず TCP・DNS・UDP のカバー範囲、必要なローカル権限、リモート側のヘルパーを確認してください。
sshuttle が選ばれるのは、SSH がすでに動いていて暗号技術が馴染み深く見えるからですが、その理由づけは適否を決める唯一の問いを飛ばしています。どのパケットが端末を出るのか、反対側でどのアカウントがそれを運ぶのか、そしてツールがどれだけのローカル権限を要求するのか。この三つの答えは転送方式によって変わるため、あるアプリケーションで動いた構成が次のアプリケーションでは静かに失敗することがあります。以下の解説は、アプリケーションが本当に必要とするプロトコルから始めます。
アプリケーションが必要とするプロトコルから始める
sshuttle 2.0 のプロトコル対応は、選ぶ方式によって決まります。Linux の NAT と nft の方式は TCP と DNS を扱い、TPROXY は一般的な UDP を追加します。プラットフォームと方式ごとに限界があり、macOS はまったく別の仕組みで横取りします。何かを選ぶ前に、インストール済みのバージョン、選択した方式、アプリケーションが必要とするプロトコルを記録してください。
したがって、TCP の要求が通っても UDP のアプリケーションやすべての DNS 参照についてはほとんど何も証明できません。sshuttle は TCP を IP パケット全体のトンネルではなくストリームとして扱うため、従来の VPN から借りたスループットの結論はここには当てはまりません。実際に動かしている仕組みと、実際にある負荷を比べてください。
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
クライアントがローカルに必要とするもの
文書化されているクライアント構成は root か sudo を必要とします。トンネルインターフェースを作るのではなくローカルの横取りルールをインストールするからで、この一点がセキュリティの物語を変えます。その権限を持つプロセスは一つのアプリケーションだけでなく端末全体の通信を転送し直せるため、権限はインストールの詳細ではなく設計の一部として扱ってください。
ツールがどのルールをインストールしたのか、そして終了時にそれが消えるのかを確認してください。横取りルールを残したまま落ちたセッションは、運用者が接続は切れたと思ったずっと後まで通信をブラックホールに送り続けることがあり、症状は残ったルールではなくネットワーク障害のように見えます。
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route最初のコマンドは典型的な呼び出しの形で、実際に必要なプレフィックスを付けます。二番目はツールが何をインストールしたかを示し、三番目はトンネルインターフェースが現れなかったことを確認しますが、これはこの設計で期待される結果です。
リモート側が動かすもの
リモート側は許可された SSH アカウントと、互換性のある Python ヘルパー環境です。制限付きシェルでログインできても、そのヘルパーを実行する許可が自動的に与えられるわけではなく、ヘルパーを実行できるアカウントがすべての対象サービスに自動的に届くわけでもありません。どちらもトラブルシューティングのメモではなく、アクセス申請に書くべき事実です。
ホストの身元確認とアカウントの認証を守ってください。最初の接続を通すために未知のホスト鍵を受け入れるとリモート側が意図した端末であるという確認が外れるため、これは単一目的の転送よりもここで重要です。
リモートアカウントを業務フローに必要なサービスに限定し、その範囲をホストの運用者と合意してください。運用者は信頼関係の一部であり、クライアント側の設定では変えられません。
信頼の境界はどこにあるか
SSH 経由でプライベート API の接続を転送しても、すべての API 操作が許可されるわけではありません。アプリケーションの TLS とアプリケーションへのログインは依然として適用され、ツールは認証のないサービスを安全にはできません。リモートホストからのさらなるホップも、その二つ目の接続がリモートホストの方針に従うため、SSH チャネルと同じ保護された区間になるとは限りません。
境界を一文にしてください。これらのプレフィックスへの通信はそのホスト上のこのアカウントを通って出ていきますが、その文に例外の段落が必要なら、設計は文書が主張する以上のことをしており、本番に届く前に再検討する価値があります。
プロトコルごとに証明してからツールを選ぶ
必要なプロトコルをそれぞれ無害な要求で試し、リゾルバの経路とアプリケーションが使うアドレスファミリーも含めてください。試験には切断も入れておくと、アプリケーションの許容される失敗の振る舞いが、障害時の驚きではなく既知の結果になります。動いている間は正しく転送していたセッションは、落ちた後に何が起きるかを何も語りません。
明示的に名前を挙げた少数のサービスには、通常のローカル転送のほうが所有しやすく監査しやすいです。その方式に合うアプリケーションの通信には、sshuttle は正当な中間手段を提供します。要件が広い IP 接続性なら、VPN の設計が正直な答えであり、選択は暗号アルゴリズムの順位ではなくカバー範囲と運用責任に従います。