Existe um servidor ftp escutando em 207.x.x.x. ? Existe um firewall e está configurado para permitir conexões com o servidor ftp?
Pergunta básica: se eu obtiver um ping decente entre saltos em uma leitura traceroute, MAS não consigo me conectar ao host via FTP, o que isso implica?
Ao conectar via FTP, eu simplesmente quero dizer usando o FileZilla e o erro é "Tempo limite da conexão esgotado". No entanto, minha traceroute de leitura para esse IP não indica um problema de latência.
Eu removi os endereços IP abaixo, mas é assim que a leitura se parece:
traceroute to 207.xxx.xxx.xx, 30 hops max, 40 byte packets
1 <server> 0.788 ms 1.135 ms 1.135 ms
2 <server> 0.677 ms 0.688 ms 0.679 ms
3 <server> 4.526 ms 4.500 ms 4.500 m s
4 <server> 1.502 ms 1.507 ms 1.502 ms
5 <server> 4.771 ms ae1.ar2.ord1.us.nla yer.net (69.31.111.146) 4.761 ms 4.734 ms
6 <server> 1.456 ms !N 1.300 ms
Alguma ideia ou sugestão? Obrigado!
Existe um servidor ftp escutando em 207.x.x.x. ? Existe um firewall e está configurado para permitir conexões com o servidor ftp?
Isso significa que o host está acessível na Internet, mas não está respondendo às tentativas de conexão ao FTP.
Isso se deve à falta de um serviço FTP em execução, a um firewall bloqueando a porta (o que é mais provável, já que você recebeu um tempo limite em vez de uma recusa) ou ambos.
Como dizem Shane Madden e Iain, as tentativas de conexão na porta TCP 21 (FTP) não estão chegando. Você pode tentar rastrear a rota usando TCP para descobrir onde a conexão está sendo descartada, por exemplo,
nmap -Pn --traceroute -p 21 207.xxx.xxx.xx
ou
tcptraceroute 207.xxx.xxx.xx 21
Primeiro um aparte rápido, para discutir os testes com a ferramenta certa.
As ferramentas ICMP são o método convencional de testar a conectividade, mas nem sempre são bons testes. Como você descobriu, você pode felizmente chegar ao seu servidor via ICMP, mas não usando FTP (rodando em cima do TCP / IP). Testar a latência do site enviando tráfego ICMP ao servidor que o hospeda produz resultados significativos e úteis? Provavelmente não. Uma ferramenta como httping ou mtr seria uma escolha muito melhor nesse caso.
O ISC tem um pequeno artigo sobre essa questão aqui: Ping é ruim (às vezes)
So for a lot of reasons, PING is simply a bad test in many situations. Either it shows things are down when they're up, or if you are using it as a measure of performance, it's not measuring what you think it's measuring.
What should people do? Well, first, test hosts for up/down status on transports that they will receive and reply with. So a webserver should probably be tested using tcp/80, not icmp echo and echo reply. Similarly, RTT (Round Trip Time) performance of networks should be measured using the protocols that we actually wish to measure. Protocols such as tcp/80 (http), tcp/443 (https), or tcp/445 (Server message block (SMB) over IP (Microsoft-DS)).
A sugestão do @Gerald Combs é excelente. Tente usar um método baseado em TCP para verificar a conectividade.
Você pode verificar se o TCP / 21 está aberto e recebendo conexões usando o telnet:
telnet 207.xxx.xxx.xx 21
Se você conseguir se conectar com êxito, poderá confirmar que pode acessar o servidor FTP (ou seja, não há firewalls bloqueando sua conexão) e o servidor FTP está em execução. Se este for o caso, o seu problema está em algum lugar na Camada de Aplicação. Como outros apontaram, é mais provável que não haja escuta do servidor FTP e / ou um firewall esteja bloqueando a conexão.
Tags networking network-speed lag