web-dev-qa-db-ja.com

SSHトンネルは、3番目のサーバーを介して2台のサーバーを接続します

私は3台のサーバーを持っています、[〜＃〜] a [〜＃〜]はインターネットでパブリックにアクセス可能なサーバーです。 [〜＃〜] b [〜＃〜]アクセスしたいWebサービスをホストします。 [〜＃〜] c [〜＃〜] AとBに接続するためのアクセス権があります。

ここで、クライアントが[〜＃〜] d [〜＃〜] Aの特別なポートにアクセスしようとすると、Bに転送されるようにします。

IPとポート

A：

  • 1.0.0.1:22SSHDサーバー
  • 1.0.0.1:443使用したいパブリックポート

B：

  • 1.0.0.2:23SSHDサーバー
  • 1.0.0.2:444アクセスしたいWebサービス

C：

  • 1.0.0.3

D：

  • 1.0.0.4

図：

  +------------+        +------------+
  | Client (D) +--------> Public (A) |
  +------------+        +-----^------+
                              |
  +----------------+    +-----------+
  | Webservice (B) <----+ Proxy (C) |
  +----------------+    +-----------+

質問：

[〜＃〜] c [〜＃〜]で実行する必要があるsshトンネルコマンドは何ですか？[〜＃〜]で1.0.0.1:443を開こうとするとd [〜＃〜] 1.0.0.2:444でホストされているサービスを取得しますか？

networkingsshssh-tunneltunneling
1
mac.1

Cでは実行できます

ssh -fNR 1.0.0.1:443:1.0.0.2:444 [email protected]

root userとしてログインした場合にのみ機能します。これは、443は特権ポートです。さらに、AのsshdがGatewayPortsをyesまたはclientspecifiedに設定して構成されている場合にのみ機能します。 （デフォルトはnoであり、yesの使用は推奨できないため、この方法で実行する場合はclientspecifiedをお勧めします）。

1
kasperd

これはSSHトンネルがどのように機能するかではありません。説明した内容に近づくことはできますが、作成した方法とは異なります。

2つのオプションが利用可能です：

  1. 使用[〜＃〜] l [〜＃〜] ocalポートフォワーディング
  2. 使用[〜＃〜] d [〜＃〜]動的ポート転送

1）ローカルポートフォワーディング

これには、アプローチを変更する必要があります。トンネルは、図のDから、クライアントから開く必要があります。達成するのは簡単です、クライアント（D）でただする

ssh -L 443:1.0.0.2:444 [email protected]

もちろん、次のことを行う必要があります。

  • dにシェルアクセスまたはPuTTYクライアントがある
  • dがログインできるプロキシ（C）上のユーザーがいる
  • ssh経由でDからCに接続できる
  • cのサーバー構成でX11ForwardingとAllowTcpForwardingをyesに設定します

ダイナミックポートフォワーディングについては後で説明します

1
AndreasPolzInfonova

編集：

@kasperdは、ユーザーにGatewayPortsを設定できるため、nginxを使用する必要がないと述べました。私は他の人のためにここで回避策を残します。

これを/etc/ssh/sshd_configに追加します

Match User <username>
   GatewayPorts yes

元の回答：

私はsshとnginxでこれを達成する解決策を見つけました。プロキシを使用してAにnginxサーバーをインストールする必要があるため、完全ではありません。 sslを有効にして、このnginxインスタンスに独自のssl証明書を与える必要がありました。

したがって、ソリューションは次のようになります。[〜＃〜] c [〜＃〜]は、次のコマンドを実行して、AとBの間にリレーを作成します。 ：

ssh -R 445:1.0.0.2:444 [email protected] -p 22

これにより、1.0.0.1のポート445の入力が1.0.0.2:444にリダイレクトされます。したがって、[〜＃〜] a [〜＃〜]のローカルユーザーは、wget https://localhost:445 --no-check-certificateを実行して、Webサービスのインデックスページを取得できるようになります。ただし、まだ公開されていません。 （不思議に思うかもしれませんが：ポート445は正しいので、次の部分ではまだ未使用のポートを使用する必要があります）

そこで、[〜＃〜] a [〜＃〜]にnginxサーバーを作成しました。これにより、トラフィックがポート443からポート445にリダイレクトされます。次の構成：

server {
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        ssl on;

        ssl_certificate /etc/nginx/ssl/server.crt;
        ssl_certificate_key /etc/nginx/ssl/server.key;

        server_name proxy.<your-domain>.com;

        location / {
          proxy_pass        https://127.0.0.1:445;
          proxy_set_header  X-Real-IP  $remote_addr;
          proxy_set_header  Host $Host;
        }
}

これで、Webブラウザ（Firefoxのシークレットモードで証明書の問題を防ぐため）を使用して、 https：// proxy .. com：443に移動し、Webサービスから結果を取得できます。 proxy..comのIPは1.0.0.1である必要があります。

ここで私が嫌うのは、[〜＃〜] b [〜＃〜にあるWebサービスの1つをリダイレクトするのではなく、新しい暗号化されたセッションを作成する新しいWebサーバーを作成する必要があることです。 ]。ただし、より良い解決策が見つかるまで、これは適切な回避策です。

0
mac.1