私はSSLに関してDebianVPS(xen domU)で問題に遭遇しました。つまり、ほとんどすべてのSSL接続がクライアントhelloでハングします。例えば:
# curl -vI https://graph.facebook.com
Opensslクライアントを使用する場合も同じです。ただし、一部のSSLトラフィックは機能します(たとえば、 https://www.nordea.se )。
サーバー
#uname -a
Linux server.com 2.6.26-1-xen-AMD64 #1 SMP Fri Mar 13 21:39:38 UTC 2009 x86_64 GNU/Linux
ただし、Dom 0(メインのxenホスト)では機能します。
Apt-get
Debianセキュリティソースでapt-getupdateを実行することすらできません(ヘッダーの読み取りにハングアップします)
Open SSL
最初は、Dom 0(0.9.8g-15 + lenny8)に新しいものがあるように見えたので、古いopensslクライアント(0.9.8o-4)があると思っていましたが、openssldebでmanuanl更新を行ってもそうではありませんでした。助けて。
SSLクライアントを開く
これは、opensslクライアントがハングしたときの完全な出力です: http://Pastebin.com/PAjwMap9
最後の考え
私はこれからがらくたをグーグルで検索しました、そして私はそれ以上得ていません。 curl、apt-getなどの問題を見てきましたが、それらはすべてアプリケーションそのものに関連するものであり、システムでは一般的ではありません。何かご意見は?
私のホスティングプロバイダーと何度か話し合った結果、私のDomUが使用していた(Dom0ではなく)IPチェーンにMTUの問題があることが判明しました。その過程で私を助けてくれたすべての人に感謝したいと思いました、あなたの助けはかけがえのないものでした:)
これは古く、すでに回答済みですが、まったく同じ問題が発生し、原因は関連していましたが、異なっていました。
重要なのは、エッジルーターでトラフィックをスニッフィングすることでした。そこでは、サーバー(GitHub.com)へのICMPメッセージがフラグメンテーションを要求しているのがわかりました。これは、再送信、重複したACKなどで接続を混乱させていました。
ICMPパケットには、奇妙な値1450のフィールドMTU of next hop
がありました。通常の値は1500です。
ルーターを確認したところ、インターフェイスの1つ(イーサネットトンネル)の値がMTUであったため、ルーターはすべてのインターフェイスの最小MTUをネクストホップとして使用していました。このインターフェースを削除すると(未使用)、SSHハンドシェイクが再び機能し始めました。
ゲストの/ dev/urandomまたは/ dev/random ..、あるいは別のデバイスの問題のように聞こえます。 straceでハングプロセスを実行し、読み取ろうとしてハングしているかどうかを確認します。
ベンが言ったように、問題が/ dev/random | urandomに関連しているかどうかを確認するために、openssl s_clientを使用してランダムファイル(「任意の」ファイル)を指定してみます。
openssl s_client -state -connect graph.facebook.com:443 -Rand anyfile
この方法でファイルを使用することは暗号化に関して非常に危険であることに注意してください。そのため、本番環境にプッシュする前に、必ず別の解決策を見つけてください。
試してみてください:
$Sudo apt-get --reinstall install openssl libssl0.9.8