Clever Geek Handbook

非常に混雑した接続を介したsshサーバーへのアクセス

この記事は私の車のサービスへの訪問の結果です。車を待っている間、ラップトップをゲストのwifiネットワークに接続し、ニュースを読みました。驚いたことに、いくつかのサイトにアクセスできなかったことがわかりました。シャトルについて知っている（そしてこのプロジェクトの大ファンであること）私は自分のサーバーとのシャトルセッションを確立しようとしましたが、うまくいきませんでした。ポート22はしっかりとブロックされていました。同時に、ポート443のnginxは正常に応答しました。次回のカーサービスへの訪問までに、サーバーにsslhマルチプレクサをインストールしました。サーバーはgentooを実行しており、/ etc / conf.d / sslhファイルに次の行を追加しました。 



DAEMON_OPTS="-p 0.0.0.0:443 --ssl 127.0.0.1:8443 --ssh 127.0.0.1:22 --user nobody"


接続のタイプに応じて、ポート443への接続はローカルポートに転送されます。



  • httpsの場合は8433（nginxはこのポートで実行されています）
  • 22sshの場合


しかし、サーバーへのssh接続を確立しようとすると、再び失敗しました。どうやら、フィルタリングはポートだけでなく、詳細なパケット調査も使用されたようです。これにより、タスクがより困難になります。Sshトラフィックはhttpsでラップする必要があります。幸い、これはwebsocatプロジェクトのおかげで難しくありません。プロジェクトページでは、多くのビルド済みバイナリを見つけることができます。何らかの理由でソースから自分でバイナリをコンパイルしたい場合も、これはそれほど難しいことではありません。これは、次の構成のhashicorpのパッカーを使用して行います。 



{
  "min_packer_version": "1.6.5",
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:20.04",
      "privileged": true,
      "discard": true,
      "volumes": {
        "{{pwd}}": "/output"
      }
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "skip_clean": true,
      "environment_vars": [
        "DEBIAN_FRONTEND=noninteractive"
      ],
      "inline": [
        "apt-get update && apt-get install -y git curl gcc libssl-dev pkg-config gcc-arm-linux-gnueabihf",
        "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs >/tmp/rustup.sh && chmod +x /tmp/rustup.sh && /tmp/rustup.sh -y",
        "git clone https://github.com/vi/websocat.git && cd websocat/",
        ". $HOME/.cargo/env && cargo build --release --features=ssl",
        "printf '[target.armv7-unknown-linux-gnueabihf]\nlinker = \"arm-linux-gnueabihf-gcc\"\n' >$HOME/.cargo/config",
        "rustup target add armv7-unknown-linux-gnueabihf",
        "cargo build --target=armv7-unknown-linux-gnueabihf --release",
        "strip target/release/websocat",
        "tar czf /output/websocat.tgz target/armv7-unknown-linux-gnueabihf/release/websocat target/release/websocat",
        "chown --reference=/output /output/websocat.tgz"
      ]
    }
  ]
}


クライアント側はubuntu20.04にあり、サーバーはnvidia tegra jetson tk1で実行されているため、armv7プラットフォームのクロスアセンブリを実行しています。私のssl終了は、着信接続を処理するnginxによって実行されるため、サーバーのビルドはsslサポートなしで実行されることに注意してください。nginxの構成は次のようになります。 



http {
    server {
        listen 0.0.0.0:8443 ssl;
        server_name your.host.com;
        ssl_certificate /etc/letsencrypt/live/your.host.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your.host.com/privkey.pem;
        location /wstunnel/ {
            proxy_pass http://127.0.0.1:8022;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
        }
    }
}


ユーザーの王冠からWebsocatを実行します。 



* * * * * netstat -lnt|grep -q :8022 || $HOME/bin/websocat -E --binary ws-l:127.0.0.1:8022 tcp:127.0.0.1:22|logger -t websocat &


これで、次のようにサーバーに接続できます。 



ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com


httpsでラップすると帯域幅はどのくらい減少しますか？これを確認するために、次のコマンドを使用しました。 



ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com 'dd if=/dev/zero count=32768 bs=8192' >/dev/null


私の実験では、帯域幅が2分の1に減少しました。ws：//プロトコルを使用する場合、つまり http、接続帯域幅はラップされていないsshと同じです。



シャトルセッションを設定する方法は次のとおりです。 



sshuttle -e 'ssh -o ProxyCommand="websocat --binary wss://your.host.com/wstunnel/"' -r your.host.com 0/0 -x $(dig +short your.host.com)/32


次回のカーサービスへの訪問では、すべてが正常に機能することを確認しました。素晴らしいボーナスとして、左側のアドレスからsshを介してサーバーにログインする試行回数が大幅に減少しました。


More articles:


All Articles