linux - ポート 443 で ssh を使用してトラフィック シェーピングを回避する

Question

ssh にポート 443 (通常は https に使用されるポート) を使用すると、暗号化されたパケットは isp には同じように見えると聞きました。

これは、トラフィック シェーピング/スロットリングを回避する方法でしょうか?

Answer 1

特定の ssh パケットが特定の https パケットと同じように「見える」かどうかはわかりません。

しかし、彼らの生涯を通じて、彼らは同じように振る舞うことはありません。セッションのセットアップと破棄は似ていません (たとえば、SSH は最初の接続時にプレーン テキストのバナーを提供します)。また、通常、https セッションは短命ではありませんか? 接続し、データを取得し、切断しますが、ssh は接続して長時間持続しますか? おそらく、22 の代わりに 443 を使用すると、素朴なフィルターを通過する可能性があると思いますが、フィルターをバイパスする積極的な試みを特に探している人をだますとは思いません。

スロットリング ssh はよくあることですか? 人々がそれをブロックした経験はありますが、スロットリングを経験したことはないと思います. ええと、私は通常、他のブロックをバイパスするために ssh トンネルを使用します。

Answer 2

443 が HTTPS に使用される場合、その暗号化は SSL (SSH ではなく) に依存します。SSH は SSL とは異なるように見えるため、ISP が実際に何を探していたかによって異なりますが、違いを検出できる可能性は十分にあります。ただし、私の経験では、この種の動作は非標準であるため、一部のパーソナル ファイアウォール ソフトウェアがブロックする可能性が高くなります。SecureSocket幸いなことに、何らかのタイプのを使用して SSL トンネルを作成するのは非常に簡単です。

一般に、トラフィックが暗号化されているかどうかに関係なく、使用している帯域幅を確認できます。彼らはまだ接続のエンドポイント、接続が開いている時間、送信されたパケットの数を知っています。繋がり。

Answer 3

ISP は、おそらく 22 よりもシェイプ ポート 443 をトラフィックする可能性が高く、22 はよりリアルタイムの応答性を必要とするためです。

実際にはプログラミングの質問ではありませんが、他の場所でより正確な回答が得られるかもしれません..