web-dev-qa-db-ja.com

sslを使用し、telnetを使用しない「ホストへのルートなし」

サーバーの1つからhttpsサイトに接続するときに奇妙な問題があります。

入力すると：

 telnet puppet 8140

標準のtelnetコンソールが表示され、いつものようにサーバーと通信できます。

Connected to athena.hidden.tld.
Escape character is '^]'.
GET / HTTP/1.1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://athena.hidden.tld:8140/"><b>https://athena.hidden.tld:8140/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.16 (Debian) Server at athena.hidden.tld Port 8140</address>
</body></html>
Connection closed by foreign Host.

しかし、sslで同じホストとポートに接続しようとすると：

openssl s_client -connect puppet:8140

動かない

connect: No route to Host
connect:errno=113

私は混乱しています。最初はファイアウォールの問題のように聞こえましたが、これは不可能でしたね。これはtelnet接続も妨げるからです。

ファイアウォールとして、私は両方のサーバーでfermを使用しています。システムはdebian squeeze vm-boxesです。

[編集1]

IPアドレスで直接接続しようとした場合でも：

openssl s_client -connect 198.51.100.1:8140 #address exchanged
connect: No route to Host
connect:errno=113

両方のホストのファイアウォールをダウンさせる

service ferm stop

また助けにはなりません。

しかし、私がするとき

openssl s_client -connect localhost:8140

サーバーマシンでは正常に接続しています。

[編集2]

telnetでIPに接続した場合も機能しません。

telnet 198.51.100.1 8140
Trying 198.51.100.1...
telnet: Unable to connect to remote Host: No route to Host

混乱はIPv6に起因する可能性があります。すべてのホストでIPv6を使用しています。 telnetはデフォルトでIPv6を使用しているようで、これは機能します。例えば：

telnet -6 puppet 8140

動作しますが

telnet -4 puppet 8140

動作しません。そのため、IPv4ルートに問題があるようです。 opensslは（またはデフォルトで）IPv4のみを使用しているように見えるため失敗しますが、telnetはIPv6を使用して成功します。

linuxsslfirewalltelnet
6
Clemens Bergmann

ターゲットホストに実際にpingできるかどうかを確認できますか？ （IPv4）のようです

  • iPv4接続が壊れている
  • aAAAとAレコードがあります
  • telnetはIPv6を優先して管理します
  • opensslはIPv6を回避します

これは単に、ターゲットホストに対して機能していないIPv4接続にまで沸騰する問題である可能性があります。 IPv4ルーティングは両方のマシンで問題ありませんか？

3
Theuni

お気づきのように、opensslでのipv6サポートの不足に直面しているようです。 LWN記事 は背景を示していますが、最も簡単な解決策（カスタムパッチを適用したopensslを再構築しない場合）は gnutls に切り替えることです。

1
pjz

使用できるTelnetによっては、IPバージョンを強制的に制限する-4または-6スイッチがあり、IPv4とIPv6の関係を除外または除外できます。

Netstat -arnの出力はどのようなものですか？宛先のIPv6ルート、および/または実行可能なデフォルトのIPv6ルートはありますか？

1
iamfromit
Connected to athena.hidden.tld.

ホスト名で接続しているようです。 IPアドレスを使用して、DNSの問題の可能性を排除してください。

openssl s_client -connect puppet.master.ip.address:8140
0
quanta

Opensslのバージョンを確認する必要があります。 113を報告する奇妙なエラーがあります...少し深く掘ると、「ハンドシェイク」の問題が発生する可能性があります。IIRC、0.9.8に問題があります...そのリビジョンにいる場合以下... opensslを更新してみてください。

これを確認してください... https://stackoverflow.com/questions/8619706/running-curl-with-openssl-0-9-8-against-openssl-1-0-0-server-causes- handshake-er/8621263＃862126

0
jim_m_somewhere