SSHクライアント経由で遠隔のPiにSOCKSプロキシを渡す

遠隔ダイナミック転送はSOCKSリスナーをPi側に置き、以降の接続をノートPCの承認済みVPN経路から行います。2台目のSSHサーバーは不要です。

SOCKSプロキシはネットワークアクセスが既にある場所で動かすもの、と考えがちです。OpenSSHはリスナーをまったく別の場所に置けます。遠隔ダイナミック転送は、遠隔ホストでSOCKSポートを開き、各接続を、ノートPCの承認済みVPN経路を運ぶローカルのSSHクライアントから発信させます。Piが得るのは範囲を限定されたプロキシであり、トンネルも権限も継承しません。

リスナーと接続の発信側は別でかまいません

通常のssh -D 1080は自分のマシンでリスナーを動かし、そこから接続を送り出します。遠隔ダイナミック転送はこれを逆にし、リスナーは遠隔ホストに現れ、受け付けた接続はすべてローカル側から開かれます。OpenSSHクライアントのマニュアルは、固定の宛先を伴わない-Rを、まさにこのSOCKS4/5の構成として記述しています。

ノートPCから実行するサポート対象のコマンドは次のとおりで、アカウント、ホスト、ポートはプレースホルダーとみなします:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

ここでは三つの点が役に立ちます。-S noneはセッションを共有コントロールマスターから遠ざけ、ExitOnForwardFailureは中途半端に開いたセッションを残さず速やかに失敗し、PermitRemoteOpenは遠隔リスナーが到達できる範囲を制限します。認可されたPiアカウントを使い、これらいずれかを追加する前にホスト鍵を検証してください。

遠隔リスナーが実際に晒すもの

リスナーに依存する前に、サーバーの転送ポリシーを確認してください。GatewayPorts noでは遠隔転送はloopbackに束縛されたままで、これが望ましい露出です。ワイルドカード転送を強制するよう設定されたサーバーは同じポートを全インターフェースで公開し、個人用プロキシをローカルネットワークから到達できるものに変えてしまいます。

loopbackもまたユーザーごとの境界ではありません。Pi上の別のプロセスがポートを知っていれば127.0.0.1:1080に接続できるので、Piのローカルアカウントとそこで動くものはすべてアクセス設計の一部です。これは宛先リストを狭く保つ理由であって、ポリシー確認を省く理由ではありません。

許可する宛先は、到達したいアプリケーションに固有のものにしてください。無関係なプログラムを動かすために無制限の転送へ置き換えると、最初の問題からはるかに遠くまで経路が広がります。宛先リストはそのセッションが何のためだったかも記録し、後で監査する人の助けになります。使ったアカウントの横に書き留めてください。

アプリケーションを一つだけプロキシ経由で通す

Pi上のプロキシ対応クライアントがその要求を出せます。socks5hという前置きは宛先名をプロキシに渡すので、名前解決と接続の両方がノートPC側で起こり、PermitRemoteOpenで指定した宛先名と一致します:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

通常の証明書検証とアプリケーション自身の認証はそのまま残してください。プロキシが変えるのはTCP接続をどこで張るかだけで、認証のないサービスを安全にはせず、自己署名のエンドポイントを信頼できるものにもしません。

ノートPCには、SSHサーバーとアプリケーションの両方への経路とリゾルバーアクセスが依然として必要です。そのSSHクライアントの通信は承認済みVPNポリシーで選択される必要があり、スプリットトンネルの除外は、試した経路とは別の経路にその通信を送ってしまうことがあります。

経路を証明し、閉じる

リスナーが想定どおりの場所にあり、意図した宛先だけが応答することを確認します:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailureは転送が確立したことを証明できますが、その先でアプリケーションのログインが成功することを保証はできません。ポートだけでなくアプリケーションを試してください。受け付けてからすべての要求を失敗させるリスナーは、通常、トンネルが失敗したのではなく宛先名かノートPCの経路が誤っていることを意味します。

この構成が運ぶのはTCPだけです。UDP、ICMP、プロキシ設定を無視するプログラムは対象外で、転送はSSHセッションが終わった瞬間に終わります。終わったらそのセッションを停止し、アプリケーションに追加したプロキシ設定を外してください。

常設のアクセスには、代わりにネットワーク所有者のサポートする登録や管理されたゲートウェイを使ってください。VPNのデバイス制限やリソース制限を回避するためにリバースプロキシを使うのは誤りで、その制限の内側で使うなら、明示的な上限を持つ認可済みのアプリケーション経路が一つ増えるだけです。

関連記事