Eu tenho um problema estranho em me conectar a um site https de um dos meus servidores.
Quando eu digito:
telnet puppet 8140
Eu sou apresentado com um console telnet padrão e posso falar com o servidor como sempre:
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.
Mas quando tento me conectar ao mesmo host e porta com ssl:
openssl s_client -connect puppet:8140
Não está funcionando
connect: No route to host
connect:errno=113
Estou confuso. No início, parecia um problema de firewall, mas isso não poderia ser, poderia? Porque isso também impediria a conexão telnet.
Como Firewall estou usando o ferm em ambos os servidores. Os sistemas são debian squeeze vm-boxes.
[editar 1]
Mesmo quando tento me conectar diretamente ao endereço IP:
openssl s_client -connect 198.51.100.1:8140 #address exchanged
connect: No route to host
connect:errno=113
Derrubando os firewalls em ambos os hosts com
service ferm stop
também não está ajudando.
Mas quando eu faço
openssl s_client -connect localhost:8140
na máquina do servidor está se conectando bem.
[editar 2]
se eu me conectar ao IP com o telnet, também não está funcionando.
telnet 198.51.100.1 8140
Trying 198.51.100.1...
telnet: Unable to connect to remote host: No route to host
A confusão pode vir do IPv6. Eu tenho IPv6 em todos os meus hosts. Parece que o telnet usa IPv6 por padrão e isso funciona. Por exemplo:
telnet -6 puppet 8140
funciona mas
telnet -4 puppet 8140
não funciona. Então, parece haver um problema com a rota do IPv4. O openssl parece apenas (ou por padrão) usar o IPv4 e, portanto, falha, mas o telnet usa o IPv6 e é bem-sucedido.
Você pode verificar se consegue pingar o host de destino? (IPv4) Parece que
Isso pode ser apenas um problema que se reduz a conexões IPv4 que não funcionam no host de destino. Seu roteamento IPv4 está OK em ambas as máquinas?
Como você observou, parece que você está correndo contra a falta de suporte a ipv6 no openssl. Um artigo do LWN fornece alguns detalhes, mas parece que a sua solução mais fácil (curta de reconstruir um openssl corrigido personalizado) é mudar para gnutls .
Dependendo do telnet disponível, pode haver um comutador -4 ou -6 para restringir a versão do IP com vigor, permitindo que você determine ou desative a preocupação IPv4 vs IPv6.
Como é a saída do fio netstat? Existem rotas IPv6 para o destino e / ou rota IPv6 padrão viáveis?
Connected to athena.hidden.tld.
Parece que você está se conectando por meio do nome do host. Tente usar o endereço IP para eliminar a possibilidade de problemas de DNS:
openssl s_client -connect puppet.master.ip.address:8140
Você tem que verificar as versões do openssl. Há um erro estranho lá fora, que relata 113 ... se você cavar um pouco mais fundo você pode ver um problema de "aperto de mão" .... IIRC, 0.9.8 teve o problema ... se você está nessa rev. ou abaixo ... tente atualizar o seu openssl.
Verifique isso ... link