日本語

English

日本語

English

Appearance

SSHトンネルとSOCKSプロキシ 技術解説ガイド ​

このドキュメントでは、レビューで推奨されている「SOCKSプロキシ（ダイナミックポートフォワード）」の仕組みと、なぜその手法が校舎環境（権限制限環境）で有効なのかを技術的に解説します。

1. SSHポートフォワーディング（トンネリング）とは？ ​

SSH接続の暗号化された通信路（トンネル）を利用して、他のポートの通信を転送する技術です。 主に以下の3種類があります。

  1. ローカルポートフォワード (-L): 特定のポートを転送する。
  2. リモートポートフォワード (-R): 接続先のポートを手元に転送する。
  3. ダイナミックポートフォワード (-D): SOCKSプロキシ として動作する。

2. ローカルポートフォワード (-L) とその限界 ​

仕組み ​

「ホストのポートA」へのアクセスを、「SSHサーバーから見たポートB」へ転送します。

bash
# ホストの 8443 を VM の 443 へ転送
ssh -L 8443:localhost:443 debian@ADDR

校舎環境（ルート権限なし）での問題点 ​

本プロジェクトでは「443番ポート（HTTPS標準）」でアクセスできることが求められます。 しかし、UNIX系OS（macOS, Linux）のセキュリティ仕様として、「1024番未満のポート（ウェルノウンポート）を開くには root (sudo) 権限が必要」 という制限があります。

  • ssh -L 443:localhost:443 ... -> Permission denied (sudoがないため失敗)
  • ssh -L 8443:localhost:443 ... -> 成功するが、URLにポート番号が必要 (https://domain:8443) になるため、厳密には要件や証明書のドメイン検証とズレる可能性がある。

このため、-L オプションはDocker Infrastructureのレビュー環境（校舎iMac等）では最適解になりにくいです。

3. ダイナミックポートフォワード (-D) = SOCKSプロキシ ​

仕組み ​

SSHクライアントが「SOCKSプロキシサーバー」として振る舞います。特定の宛先ポートを固定せず、プロキシとして受け取った通信リクエストをそのままSSHサーバーへ送り出します。

bash
# ホストの 8080 を SOCKSプロキシとして待受
ssh -D 8080 -N debian@ADDR
  • 8080番などの1024番以降のポートを使うため、一般ユーザー権限で実行可能です。

動作フロー（Docker Infrastructureの場合） ​

  1. ブラウザ (Firefox): 「https://local.dev に行きたい」というリクエストが発生。
  2. SOCKS設定: 設定により、そのリクエストを直接インターネットに投げず、ローカルの localhost:8080 (SSH) に渡す。
  3. SSHトンネル: リクエストを暗号化して VM (Debian) に転送。
  4. VM側 (SSHサーバー): 受け取ったリクエストを代理で実行。ここで名前解決を行う。
    • 「local.dev ってどこ？」→ /etc/hosts を見て「俺 (127.0.0.1) だな」と解決。
  5. 接続: VM内の NGINX (443) に接続し、結果をホストに送り返す。

なぜこれが「最強」なのか？ ​

  • ポート番号維持: ブラウザ上ではあくまで https://local.dev (ポート443) へのアクセスとして扱われます。
  • 権限不要: ホスト側でroot権限が不要です。
  • DNS解決の委譲: ホストの /etc/hosts を汚さず、VM内の設定を利用できます（Firefoxの Proxy DNS 設定が必要）。

4. 一般的なSOCKSプロキシの利用シーン ​

Docker Infrastructure以外でも、エンジニアの実務で頻繁に使われます。

  1. 踏み台サーバー (Bastion) 経由のアクセス:
    • クラウドのDB（AWS RDSなど）はプライベートネットワークにあり、直接アクセスできません。
    • 踏み台サーバーにSSHでSOCKS接続し、手元のDBクライアントからプライベートIPで接続する際によく使われます。
  2. ファイアウォール回避:
    • 厳格な社内NWから、SSH（22番）さえ通れば、Webフィルタリングなどを回避して自由なブラウジングが可能になります（※組織のポリシー違反になる場合があるので注意）。
  3. 地域制限の回避:
    • 海外のサーバーをSOCKSプロキシにすることで、その国からのアクセスとしてWebサイトを閲覧できます。

5. まとめ ​

項目ローカルポートフォワード (-L)SOCKSプロキシ (-D)
転送先固定（例: 443のみ）動的（何番ポートでもOK）
443使用root権限が必要不要（SSH入口ポートだけ指定）
設定コマンドが少し複雑ブラウザ側の設定が必要
用途特定の1サービスの公開ネットワーク全体の利用、ブラウジング
Docker Infrastructure× (校舎で使いにくい)◎ (推奨)

6. ホストOSからの接続を簡単にする設定 (~/.ssh/config) ​

毎回 ssh -p 4242 -D 8080 debian@192.168.65.11 と打つのは大変です。 ホストOS（Mac/Windows）の ~/.ssh/config ファイルを設定することで、コマンドを短縮できます。

設定手順 (ホストOS側) ​

  1. ~/.ssh/config を編集（なければ作成）します。

    bash
    vim ~/.ssh/config

  2. 以下の設定を追加します。

    bash
    Host inception
    HostName 192.168.65.11
    User debian
    Port 4242
    # SOCKSプロキシを自動で有効にする場合（任意）
    DynamicForward 8080
    # 接続切れ防止（推奨）
    TCPKeepAlive yes
    ServerAliveInterval 60
    ServerAliveCountMax 30

設定オプションの解説 ​

  • DynamicForward 8080: SOCKSプロキシを有効にします。
  • KeepAlive設定の関係性:
    • TCPKeepAlive yes: OSレベル（TCP層）で生存確認を行います。切断検知は早いですが、中継機器（ファイアウォール）によってはこのパケットを無視して「通信なし」とみなす場合があります。
    • ServerAliveInterval 60: SSHアプリレベル（アプリケーション層）で暗号化されたパケットを送ります。ファイアウォールからは「通常の通信」に見えるため、切断回避に最も効果的です。
    • ServerAliveCountMax 30: 応答がない場合に何回まで耐えるか（60秒×30回＝30分）。
    • 結論: 両方設定することで、OSレベルの不具合検知と、アプリレベルのアイドル対策を二重に行い、接続を盤石にします。

使用方法 ​

設定後は、以下の短いコマンドだけで接続（兼SOCKSプロキシ起動）が可能になります。

bash
# 通常の接続（シェル操作 + SOCKSプロキシ有効）
ssh inception

# SOCKSプロキシとして接続（configにDynamicForwardを書いていない場合）
ssh -D 8080 -N inception

これで、レビュー時もスムーズに環境への接続を実現できます。

Q. DynamicForward を書くとターミナル操作できなくなりますか？ ​

A. いいえ、できます！~/.ssh/config に書いた場合、SSH接続すると「通常のシェル操作」と「バックグラウンドでのポート転送」が同時に有効になります。 ゲストOSの中でコマンドを打ちながら、裏でブラウザ通信も通すことができるため非常に便利です。

（※ コマンドラインで -N オプションを付けた場合のみ、シェルが開かず転送専用になります）

Released under the MIT License.

Copyright © 2026 kamitsui