☰

¿Cómo identificar y abordar la causa raíz de un tiempo de espera de conexión?

tag-icon • tag-icon linux networking centos centos6 linux-networking
¿Cómo identificar y abordar la causa raíz de un tiempo de espera de conexión?

Fondo:Estoy intentando conectarme a un servidor SFTP para transferir algunos archivos. Sin embargo, noté que no puedo conectarme desde un servidor en particular. Puedo conectarme desde otras máquinas en la misma red, por lo que podría decir que puede haber algún problema local con ese servidor.

SERVER-OK#1   ---> sftpserver.com:22
SERVER-FAIL#2 ---> sftpserver.com:22

Lo que he probado/descubrí hasta ahora:

  1. traceroute- hay diferentes resultados de seguimiento. El servidor que falla no finaliza el seguimiento.

    traceroute to sftpserver.com (10.10.10.10), 30 hops max, 60 byte packets 
1  10.10.10.1 (10.10.10.254)  0.681 ms  1.209 ms  1.435 ms 
2  99.99.99.99 (99.99.99.254)  1.890 ms  1.820 ms  1.741 ms
3  * * *
4  * * *
30 * * *

  2. ping- Se agota el tiempo de espera para sftpserver.com solo desde SERVER-FAIL#2. Puedo hacer ping a Google, etc., pero no a sftserver.com. Si se hace desde otros servidores, el ping está bien.

  3. iptables- desactivado.
  4. proxies- http_proxyestá preparado bash_profile.
  5. firewall- permite el puerto 22 SSH.
  6. reboot server- ¿Yo se, verdad? Estoy un poco desesperado.

¿Hay algo más que debería inspeccionar?

Respuesta1

Si sabe que funciona desde otros servidores, entonces sólo tiene que determinar qué es diferente en la relación entre los dos servidores que no funcionan. Dado que su rastreo está agotando el tiempo de espera y el ping falla, existe un problema básico de conectividad entre esos hosts. Compare la configuración entre el servidor defectuoso y los hosts buenos conocidos. En particular:

  • ¿Está configurada la puerta de enlace y coincide con otros hosts de la subred?
  • ¿Son correctas la dirección de red y la máscara de subred?
  • ¿Puede el host problemático llegar correctamente a cualquiera o todos los demás hosts de la red?
  • ¿Ese traceroute incorrecto recorre el mismo camino que los exitosos de otros hosts?

Una máscara de subred que esté ligeramente apagada, por ejemplo, le permitirá llegar bien a casi todos los demás hosts, pero hace que un subconjunto particular sea "invisible" porque su host no cree que esté en la misma red local. El route -ncomando debería mostrarle la información básica de puerta de enlace, red y subred.

información relacionada