Por que o SSH via IP remoto seria mais rápido que o IP local?

3

Eu tenho um servidor Linux em execução na minha casa, com uma configuração de URL do DynDNS apontando para o meu endereço IP público.

Uma das coisas que notei é usar o endereço remoto como url.dyn-dns.tv ou meu IP público se conecta mais rápido ao servidor em comparação com o meu local 192.168.xx.xx .

Alguém tem alguma idéia de por que isso pode ser?

    
por Grant 31.08.2012 / 11:36

3 respostas

8

tl; dr Corrige a configuração do resolvedor de DNS no servidor. (uma solução é desativar as pesquisas reversas no SSHD, mas é melhor corrigir o que está corrompido)

Resposta original

Anyone have any ideas why this might be?

Não realmente, mas aqui está uma anedota que pode ajudar:

No passado, com um protocolo diferente, quando uma conexão demora muito para ser estabelecida, descobri que uma causa é o tempo limite de DNS, pois o servidor tenta procurar o nome de um endereço IP para registrar o nome do cliente. em seus logs. Se o endereço IP do cliente não for conhecido corretamente para o serviço DNS local e o DNS não estiver configurado corretamente, o servidor poderá aguardar muito tempo para que o DNS atinja o tempo limite.

A maneira de procurar esse tipo de efeito é executar sniffers de rede, inicialmente no cliente, mas também no servidor, e você poderá ver algum tráfego de rede relacionado à conexão, que leva muito tempo para chegar uma resposta, ou que não recebe resposta (você pode ver novas tentativas)

tcpdump e wireshark são bons.

Atualização 1

No cliente com o atraso na conexão

  • encontre o endereço IP do cliente

    • No Windows, abra uma janela de prompt de comando e digite ipconfig
    • No Linux, abra uma janela de terminal e digite ifconfig -a
  • opcionalmente, confirme que você pode procurar rapidamente o endereço IP do servidor

    • no windows nslookup servername
    • no Linux dig servername ou host servername se o seu não tiver escavação.

No servidor

  • procure o nome do cliente
    • verifique em /etc/resolv.conf o endereço do primeiro servidor de nomes DNS
    • digite dig -x 192.168.n.m @nameserver ou host 192.168.n.m server em que 192.168.n.m é substituído pelo endereço IP real do cliente e nameserver é o endereço IP do servidor de nomes.
    • repita para outros servidores de nomes listados em /etc/resolv.conf

o servidor deve receber uma resposta em milissegundos. Com uma configuração de DNS quebrada, levará vários segundos para expirar.

boa configuração

# time host 192.168.3.4
Host 4.3.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

real    0m0.130s
user    0m0.000s
sys     0m0.020s

configuração incorreta

# echo nameserver 1.2.3.4 > /etc/resolv.conf
# time host 192.168.3.4
;; connection timed out; no servers could be reached

real    0m10.010s
user    0m0.000s
sys     0m0.010s

Observe o atraso de 10 segundos. Isso significa que qualquer serviço SSH que queira ter nomes de clientes em seus registros levará 10 segundos para configurar uma conexão SSH.

Atualização 2

Acontece que este Q é (provavelmente) uma cópia exata de Por que o prompt de 'senha' demora para sempre quando eu SSH no meu Servidor Ubuntu 9.05?

Solução

Corrija a configuração do resolvedor de DNS no servidor.

    
por 31.08.2012 / 12:13
3

Eu estou supondo que você não está executando um DNS local, então quando o servidor ssh tenta fazer uma pesquisa reversa de DNS, ele está esperando por um tempo limite. Quando você está se conectando ao endereço externo, você está sendo NAT através de um endereço IP que transmite o DNS.

Para desativar as pesquisas reversas de DNS, você terá que editar seu arquivo sshd_config e encontrar a linha "UseDNS" e configurá-lo para "não". (Você terá que reiniciar o sshd para que ele tenha efeito). Alternativamente, você pode configurar seu próprio servidor DNS para sua sub-rede local. (DNSMasq é um bom e leve para brincar se você não quer mexer com o BIND)

    
por 06.09.2012 / 18:03
1

Você pode tentar chamar ssh com a opção detalhada: ssh -v -v -v .
Isso pode fornecer algumas informações úteis.

Uma explicação que posso pensar é se o seu servidor está ouvindo no iPv4, mas você ainda tem iPv6 ativado no seu sistema local. O tempo de espera seria então quando o ssh está tentando em vão para acessar o servidor no iPv6, depois desiste e tenta o iPv4 com sucesso.

Em qualquer caso, sugiro verificar quais adaptadores de rede estão ativados e desativar aqueles que são inúteis.

    
por 05.09.2012 / 20:18