☰

Wie lässt sich die Grundursache eines Verbindungstimeouts ermitteln und beheben?

tag-icon • tag-icon linux networking centos centos6 linux-networking
Wie lässt sich die Grundursache eines Verbindungstimeouts ermitteln und beheben?

Hintergrund:Ich versuche, eine Verbindung zu einem SFTP-Server herzustellen, um einige Dateien zu übertragen. Allerdings habe ich festgestellt, dass ich von einem bestimmten Server aus keine Verbindung herstellen kann. Ich kann von anderen Rechnern im selben Netzwerk aus eine Verbindung herstellen, daher könnte es sein, dass lokal mit diesem Server etwas nicht stimmt.

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

Was ich bisher versucht/herausgefunden habe:

  1. traceroute- Es gibt unterschiedliche Trace-Ergebnisse. Der fehlerhafte Server beendet den Trace nicht.

    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- Zeitüberschreitung für sftpserver.com nur bei SERVER-FAIL#2. Ich kann Google usw. anpingen, aber nicht sftserver.com. Wenn ich es von anderen Servern aus mache, ist der Ping in Ordnung.

  3. iptables- deaktiviert.
  4. proxies- http_proxyist in eingestellt bash_profile.
  5. firewall- ermöglicht SSH über Port 22.
  6. reboot server- Ich weiß, oder? Ich bin irgendwie verzweifelt.

Gibt es sonst noch etwas, das ich überprüfen sollte?

Antwort1

Wenn Sie wissen, dass es von anderen Servern aus funktioniert, müssen Sie nur feststellen, was an der Beziehung zwischen den beiden Servern, die nicht funktionieren, anders ist. Da Ihr Trace abläuft und der Ping fehlschlägt, besteht ein grundlegendes Verbindungsproblem zwischen diesen Hosts. Vergleichen Sie die Einstellungen zwischen dem fehlerhaften Server und den bekanntermaßen funktionierenden Hosts. Insbesondere:

  • Ist das Gateway eingestellt und stimmt es mit anderen Hosts im Subnetz überein?
  • Sind die Netzwerkadresse und die Subnetzmaske korrekt?
  • Kann der Problemhost alle anderen Hosts im Netzwerk ordnungsgemäß erreichen?
  • Verläuft dieser fehlerhafte Traceroute über denselben Pfad wie die erfolgreichen Traceroutes anderer Hosts?

Eine leicht abweichende Subnetzmaske ermöglicht es Ihnen beispielsweise, fast alle anderen Hosts problemlos zu erreichen, macht aber eine bestimmte Teilmenge „unsichtbar“, da Ihr Host nicht glaubt, dass er sich im selben lokalen Netzwerk befindet. Der route -nBefehl sollte Ihnen die grundlegenden Gateway-, Netzwerk- und Subnetzinformationen anzeigen.

verwandte Informationen