HTTPSを介したトンネル
私の職場では、交通ブロッカー/ファイアウォールが次第に悪化しています。ポート22でホームマシンに接続できず、sshアクセスがないので悲しくなります。以前はSSHをポート5050に移動することで使用できましたが、最近のフィルターの中には、このトラフィックをIMとして扱い、別のプロキシ経由でリダイレクトするものがあると思います。それが私の最善の推測です。いずれにせよ、ログインする前にssh接続が終了するようになりました。
最近、ポート443がまだ無秩序であるため、HTTPS経由でAjaxtermを使用していますが、これは理想からはほど遠いものです。 （端末エミュレーションがうまくいかない、ポートフォワーディングがない、ブラウザが驚くべき速度でメモリリークを起こす...）_mod_proxy_connect_の上に_mod_ssl_を設定してみましたが、_CONNECT localhost:22 HTTP/1.1_ HTTPS経由でリクエストすると、すべて設定されます。悲しいことに、これは機能しないようです。リクエストの送信が完了するまで、HTTPS接続は機能します。その後、SSLがクラップスします。 _mod_proxy_connect_を介してパイプを継続するのではなく、_mod_ssl_が接続全体を引き継ぐように見え、HTTPSクライアントからの混乱を招きます。
これを機能させる方法はありますか？いくつかの理由から、プレーンHTTPでこれを実行したくありません。
- そのような大きな太ったオープンプロキシを残すことはただ悪臭を放ちます
- 大きなファットオープンプロキシはHTTPSでも良くありませんが、認証が必要なので私には問題ないと感じます
- HTTPはプロキシを通過します-トラフィックがスニッフィングされることについてはあまり心配していませんsshが「プレーンテキスト」を通過するためトンネル-しかし、基本的にプロキシできないHTTPSよりもマングルされる可能性がはるかに高い
要件：
- 他のHTTPSトラフィックを妨げることなく、ポート443で動作する必要があります（つまり、HTTPSでページを提供できなくなるため、sshサーバーをポート443に配置することはできません）
- Windows（またはCygwin）で実行される単純なポートフォワーダークライアントを持っているか、書くことができます
編集
DAG：HTTP（S）を介したSSHのトンネリング が指摘されましたが、役に立ちません：記事の最後に バグ29744-CONNECTが機能しません）既存のSSL接続を介して HTTPSを介したトンネリングの防止、まさに私が遭遇した問題。この時点で、私はおそらくいくつかのCGIスクリプトを検討していますが、より良いソリューションが利用できる場合は、それを要件としてリストしたくありません。
会社がそのような制限的な方針を持っている理由を調べてください。それは正当な理由かもしれません。
それでもポリシーをバイパスしたい場合は、ポート443でサーバーをリッスンし、要求に応じて、トラフィックをWebサーバーまたはSSHデーモンに転送する小さなプロキシを作成できます。ただし、2つの問題があります。
HTTPSリクエストかSSHリクエストかを判断するには、（小さな）タイムアウトでデータを読み取ろうとする必要があります。これは、TLS/SSLハンドシェイクはクライアントがデータを送信することから始まり、SSHハンドシェイクはサーバーから始まるためです。いくつかのデータを送信します。タイムアウトは、TLS/SSLハンドシェイクでクライアントからの初期データの配信を遅らせるのに十分な大きさである必要があるため、SSH接続の確立が遅くなります。
会社のHTTPプロキシがスマートな場合、ポート443に
CONNECTすると、予想されるTLS/SSL「ハンドシェイク」を実際に盗聴し、TLS/SSLハンドシェイクではないことを検出すると、 SSH接続の試行を終了する可能性があります。これに対処するには、SSHデーモンをTLS/SSLトンネル（例：stunnel）にラップできますが、クライアント要求のTLS/SSLバージョンに基づいて要求を区別し、次のことを判断する必要があります。 TLS/SSL接続をWebサーバーまたはTLS/SSLトンネリングSSHデーモンにルーティングします。
Iptablesを使用して、作業マシンからsshにsshトラフィックを転送し、ポート443でホームサーバーに接続している他のすべてのマシンがApacheサーバーを取得できるようにする必要があります。
次のようなルールを試してください。
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22
ここで、111.111.111.111はオフィスコンピュータのIPアドレスです。
これはすべて、Linux> = 2.4を実行していることを前提としています。これは、今ではそうなっているはずです。それはほぼ10年前から出ています。
Iptablesのドキュメントは http://www.netfilter.org にあります。
自宅でOpenVPN2.1サーバーをセットアップし、ポート443を使用します（自宅にポート443でHTTPSサービスをセットアップする場合は、OpenVPNのポート共有オプションをトリガーしてポート443でOpenVPNとHTTPSの両方のトランザクションを処理します。この機能は非Windows OS）
次に、ラップトップのOpenVPNクライアントをロードウォリアーモードでセットアップして、自宅のOpenVPNサーバーにアクセスします。 OpenVPNで作成した安全なVPNネットワーク内で、自宅や好きな場所に電話をかけることができます。この目的でSSHを使用する必要はなくなりました。
仲買人を設置してもらえますか？
443でSSHをリッスンしているクラウドでsmall/free/cheapインスタンスを実行し、そのクラウドインスタンスをお気に入りのポート（22など）のホームボックスにトンネリングします。
確かにレイテンシーがいくらか追加されますが、元のホームセットアップをそのままにしておくという問題は解決されます。
マシンで2つのIPアドレスを使用するのはどうですか？
Apache/httpsを一方のIP_1：443にバインドし、sshdをもう一方のIP_2：443にバインドしますか？
現在使用していないポートを見つけて、それを聞く必要があると思います。 443は明らかな候補ですが、それは不可能だとあなたは言います。メール（25、110、143）、telnet（23）、ftp（21）、DNS（53）、さらにはwhois（43）はどうですか？
ここで悪魔の代弁者になって本当に申し訳ありませんが、彼らがあなたの職場でポートをブロックしている場合、それはおそらく人々がセキュリティを侵害することを望まないためです。
さて、上司からトンネルを開く許可を得れば、それは問題ありませんが、何かが起こった場合、何でも、あなたがトンネルを持っていると彼らが理解した場合、私はあなたがスケープゴートになることをほぼ保証できます。ですから、もし私があなただったら、ファイアウォールを設置していれば、職場でトンネルを開くことはないでしょう。
プロキシトンネルがあなたの答えかもしれません
http://proxytunnel.sourceforge.net/
私のsshサーバーがHost.domain.tldで、私のWorksプロキシサーバーが10.2.4.37だとしましょう
これをローカルのssh設定に追加します
ホストhost.domain.tldProxyCommand/usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d％h：％p ProtocolKeepAlives 30
SSLが関与していない場合、ApacheはCONNECTにまったく問題がないため、SSL機能をオフにし、stunnelを使用してサイトのhttpsバージョンを提供します。これは再コンパイルを必要とせず、サイトがhttpsを正常に提供できるようにします。これまでのところ、私が知っている最もクリーンな回避策。
詳細については、 http://chm.duquesne.free.fr/blog/?p=281 を参照してください。
AjaxTermを介して次の設計を使用して、会社のファイアウォールをバイパスすることができました。これは機能します。
会社のネットワーク上のPC-> https経由の会社のプロキシ->インターネット-> SSL上の自宅のApacheリバースプロキシサーバー+ .htpasswd保護-> AjaxTermサーバー（これ以降、他のサーバーにSSHで接続できます）。
それでも完璧な世界ではありません... HTTPS経由でホームネットワークにトンネリングできれば良いでしょう。
他のHTTPSトラフィックを妨げることなく、ポート443で動作する必要があります（つまり、HTTPSでページを提供できなくなるため、sshサーバーをポート443に配置することはできません）
HTTPSサーバーを別のポートにバインドすることは可能ですか？用途によっては、自宅にSSHで接続し、そこからlynxを使用するだけでは、職場から直接アクセスできないという問題を回避できる場合もあります。
それでは、プロキシを試してみてください（-HTTPプロキシサーバーをサポートしています）！