У меня странная проблема с подключением к 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-box.
[изменить 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]
если я подключаюсь к IP с помощью telnet, он тоже не работает.
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 и успешно.
Можете ли вы проверить, действительно ли вы можете проверить связь с целевым хостом? (IPv4) Похоже, что
Это может быть просто проблема, заключающаяся в том, что соединения IPv4 не работают с целевым хостом. В порядке ли ваша маршрутизация IPv4 на обеих машинах?
В зависимости от того, какой Telnet у вас есть, может быть переключатель -4 или -6 для принудительного ограничения версии IP, позволяющий исключить или разрешить проблему IPv4 и IPv6.
Как выглядит вывод netstat -arn? Существуют ли жизнеспособные маршруты IPv6 для пункта назначения и / или маршрут IPv6 по умолчанию?
Как вы заметили, похоже, что вы столкнулись с отсутствием поддержки ipv6 в openssl. An LWN статья дает некоторый фон, но похоже, что ваше самое простое решение (за исключением восстановления пользовательского исправленного openssl) - это переключиться на Gnutls.
Connected to athena.hidden.tld.
Похоже, вы подключаетесь через имя хоста. Попробуйте использовать IP-адрес, чтобы исключить возможность проблем с DNS:
openssl s_client -connect puppet.master.ip.address:8140
Вы должны проверить версии openssl. Там есть странная ошибка, которая сообщает 113 ... если вы копнете немного глубже, вы можете увидеть проблему "рукопожатия" ... У IIRC, 0.9.8 была проблема ... если вы на этой версии. или ниже ... попробуйте обновить свой openssl.