ポート 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 が実際に何を探していたかによって異なりますが、違いを検出できる可能性は十分にあります。ただし、私の経験では、この種の動作は非標準であるため、一部のパーソナル ファイアウォール ソフトウェアがブロックする可能性が高くなります。幸いなことに、次のコマンドを使用して SSL トンネルを作成するのは非常に簡単です。 SecureSocket ある種の。

一般に、トラフィックが暗号化されているかどうかに関係なく、使用している帯域幅の量を確認できます。彼らは接続のエンドポイント、接続が開かれている時間、送信されたパケットの数を引き続き知っているため、この種のデータに基づいて形成メトリクスを作成している場合、接続のスロットルを防ぐためにできることは何もありません。繋がり。

Answer 3

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

実際にはプログラミングの質問ではありませんが、おそらく別の場所でより正確な回答が得られるでしょう。