confiabilidade da nossa conexão com a internet

Question

Eu tenho um servidor em um local remoto. Ao se conectar a essa máquina usando o SSH, ela fica desconectada, dizendo:

Read from remote host XXXX: Connection reset by peer
Connection to XXX closed.

Estou duvidando disso como um problema com a conexão com a Internet, porque o ping para essa máquina mostra o tempo limite de solicitações em intervalos aleatórios. Eu tentei até mesmo pingar o Google, que também mostrou tempo de solicitação.

Como posso confirmar que é um problema com a Internet / qual é o erro real?

Mais informações:

Temos um túnel VPN entre a nossa rede e a rede remota. Então eu posso ssh máquina remota usando um dos IP local que ele ganha. e tracert para que termine em 2 esperanças com sucesso.

    

Answer 1

eu recomendo que você use o comando traceroute. No Windows, é encurtado para 'tracert'

por exemplo, abra o prompt de comando e digite o seguinte (-d significa que não faça pesquisas de DNS):

tracert -d <your server ip address>

isto lhe dará uma lista de todos os saltos que um pacote TCP atinge ao longo do caminho para o alvo. O último salto bem sucedido antes de você obter um tempo limite lhe dará uma idéia de onde a internet está falhando. Pode ser o seu wifi, o seu ISP ou qualquer outra coisa.

Outra idéia é que às vezes a conexão SSH pode ser descartada porque o sistema acha que a conexão está inativa e está ok para descartá-la. Isso também pode ser uma configuração no seu modem. Mas eu acho que traceroute lhe dará uma boa idéia do ponto de falha. Se você nunca pegar uma falha com traceroute, eu diria que talvez algo esteja ativamente soltando sua conexão ociosa. Veja as configurações do tipo Keep-Alive no seu modem Wifi Router / DSL, etc.

Mas publique suas descobertas e vamos ver se podemos ajudá-lo a descobrir isso.

boa sorte.

    

Answer 2

Eu aconselharia a instalação de algo como fumaça . Isso lhe dará estatísticas ao longo de um período de tempo que você pode usar para ir bater seu ISP em fornecer um serviço decente.

    

Answer 3

Execute uma captura de rede em sua máquina enquanto estiver conectado à máquina remota. Quando a desconexão ocorre, procure na captura um TCP RST (reset) da máquina remota. Se você encontrar, o problema é com a máquina remota. Se você não fizer isso, o problema está em algum lugar na conexão entre os dois.

    

Answer 4

Com todo o respeito, não quero dizer que o tracert sempre falhe. Quero dizer que quando um host no caminho não responde a um tracert, isso não significa que esse host é o problema, e se você usar muito tracert, verá que, invariavelmente, sempre parece haver um host no caminho. que não responde.

O problema aqui é com a conexão caindo de forma intermitente. Se fosse difícil usar tracert e ping seria uma boa escolha. Ping e tracert são boas ferramentas de nível de triagem, mas não ajudam a descobrir a causa de problemas intermitentes. Tracert (como o próprio nome indica) é uma ferramenta para rastrear a rota para um host remoto, e por sua natureza pode dizer se um caminho existe ou não. Tracert não é uma ferramenta de diagnóstico que pode dizer por que um host não está respondendo ou está descartando pacotes. A única maneira de obter essas informações é executar uma captura de rede em ambas as extremidades da conexão e, idealmente, se possível, em cada link no caminho.

Se eu executar um ping constante e um tracert constante para um host remoto e obtiver uma resposta de ping com falha do host remoto e no mesmo momento ver um host intermediário no tracert parar de responder, isso significa que esse host intermediário é o problema? Não, não e agora haveria maneira de correlacionar os dois eventos, a menos que eu estivesse executando uma captura de rede em cada link no caminho e pudesse analisar os dados no nível do pacote.

Eu estava simplesmente sugerindo iniciar o problema com os componentes conhecidos e mensuráveis, que são os dois hosts em cada extremidade da conexão.

Eu sei que todos têm sua própria opinião e minha intenção não é começar uma guerra, então peço desculpas se alguém se ofender.

    

Answer 5

Você tem alguma coisa no lugar que possa estar restringindo ou limitando as conexões SSH na máquina, como iptables (Linux) ou inetd.conf (FreeBSD)? O que acontece se você esperar 5 ou 15 minutos antes de tentar novamente a conexão?