Por que um handshake TLS leva * para sempre * (20 segundos) em um VPS?

4

Eu tenho um servidor que geralmente funciona bem, mas fica preso por 20 segundos ao tentar se conectar com SSL (SSH ou HTTPS exibem o mesmo padrão).

Eu tentei várias conexões sem SSL, como um telnet:

telnet server-name 80

Inseriu um comando GET

GET http://server-name/
Host: server-name
Accept: text/html, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

E a resposta é 100% instantânea.

No entanto, quando tento conectar-me ao servidor via HTTPS no meu navegador, ou uso o SSH para se conectar ao mesmo servidor, ele fica por cerca de 20 segundos antes de se conectar.

Para o SSH, ele funcionará bem (ou seja, não será mais lento). Para HTTPS, será lento cada vez que tiver que se conectar novamente. Uma conexão que não seja fechada continuará funcionando rapidamente.

Estou adicionando uma captura de tela das informações da Rede que aparecem no Firebug. Como podemos ver, cada vez que uma nova conexão é tentada, 20s. Olhando para o uso do servidor com htop, a CPU está em 0% e quando algo acontece, vai para um whooping de 0,01% para o 1 min. relatório de uso. Portanto, o servidor não está sendo rastreado de forma alguma (ou seja, é um servidor de teste neste momento e ainda não temos acesso a outros.)

Então, minha pergunta é: o que poderia causar essa lentidão?

Eu pensei que talvez pudesse ser que o OpenSSL estivesse tentando usar / dev / random, mas eu nunca ouvi falar de um problema como esse antes. O dispositivo aleatório não produz muito nada nesse VPS. No entanto, / dev / urandom funciona muito bem. Eu posso conseguir 1Mb de dados aleatórios em poucos segundos. O que eu poderia investigar para corrigir esse problema?

/etc/resolv.conf parece com o DNS do Google. Deve ser rápido ...

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 8.8.4.4

Note que a configuração do Apache2 em si não deve importar diretamente, pois isso também acontece com o SSH ...

Também tentei com ssh -vvv . A conexão é instantânea.

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/alexis/.ssh/config
debug1: /home/alexis/.ssh/config line 202: Applying options for do-nia2match
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/alexis/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 178.62.213.172 [178.62.213.172] port 22.
debug1: Connection established.
...
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/alexis/.ssh/do-nia2match_rsa, explicit

SUPER LONG PAUSE HAPPENS HERE (~20s)

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive
debug3: authmethod_lookup publickey
...

Não sei ao certo por que, ao enviar a chave, o servidor SSH ficaria suspenso por 20 segundos ...

    
por Alexis Wilke 14.02.2016 / 00:59

1 resposta

1

Eu descobri (no caminho de volta - veja os comentários) que eu estava bloqueando todos os 127.0.0.0, exceto os endereços 127.0.0.1.

Debian e, portanto, o Ubuntu define uma entrada no seu /etc/hosts em 127.0.1.1 com o seu nome de domínio. Você deve ver algo assim no início do seu arquivo /etc/hosts :

127.0.1.1     hostname.example.com hostname

Eu tive que revisar meu firewall e, na verdade, decidi abrir todos os 127.x.x.x, já que todos fazem parte da rede privada e são todos IPs seguros.

    
por 04.10.2018 / 00:46