Telnet

Hallo Leute,

ich habe ein Problem mit meinem Server, ich versuche auf ihn zu zugreifen mit

ssh [email protected]

dann kommt die Meldung

#14442: ssh: connect to address 172.25.231.159 port 22: No route to host

dann versuche ich mit telnet zu gucken, ob der Server antwortet, mit

#telnet 172.25.231.159 7

dann kommt diese Meldung

#telnet: connect to address 172.25.231.159: No route to host

Kann mir jemand sagen, welche Einstellugen ich vornehmen muss, damit dieses geht???

Danke im VOraus!! Gruss!!

Routing Problem oder Server offline
Moien

#14442: ssh: connect to address 172.25.231.159 port 22: No
route to host

Dein Netzwerk kann den Rechner nicht finden. D.h. irgendwo in deinem Routing läuft was schief oder der Rechner ist aus/offline.

Versuch mal:
ping 172.25.231.159

und kuck wo er aussteigt.

cu

Das ist ja das Interessante dabei, das er niergends aussteigt, anpingen klappt auch, es verliert keine Packete!!
Vielleicht ist irgendein Service aus oder soo???

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Moien

Das ist ja das Interessante dabei, das er niergends aussteigt,
anpingen klappt auch, es verliert keine Packete!!

Dann filtert dir irgendein Witzbold die TCP-Packete weg und lässt ICMP durch.

Hast du Zugang zu den Routern zwischen dir und dem Server ?

cu

Ich kann die Route anpingen aber nicht draufgehen und Witzbolde gibt es hier nicht im System, es muss ein anderes Problem sein, irgendwo in den Einstellungen???

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo,

Das ist ja das Interessante dabei, das er niergends aussteigt,
anpingen klappt auch, es verliert keine Packete!!
Vielleicht ist irgendein Service aus oder soo???

Dann lass mal traceroute auf die IP los, und poste uns die Ausgabe davon sowie von ifconfig und route.

Gruesse,
Moritz

Hallo,

Dann lass mal traceroute auf die IP los, und poste uns die
Ausgabe davon sowie von ifconfig und route.

Gruesse,
Moritz

Hier ist das Ergebnis von traceroute:

#traceroute 172.25.231.159
#traceroute to 172.25.231.159 (172.25.231.159), 30 hops max, 40 byte #packets

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 asa30-4 (172.25.231.159)(H!) 0.818 ms (H!) 0.770 ms (H!) 0.760 ms

netstat -r liefert:

#192.168.1.0 * 255.255.255.0 U 0 0 #0 eth1
#172.25.231.0 * 255.255.255.0 U 0 0 #0 eth0
#default 172.25.231.1 0.0.0.0 UG 0 0 #0 eth0

Ich hoffe das hilft euch und mir, was ich nicht glaube, weil alles eingestellt ist, wie route etc.

gruss

Hi…

#traceroute 172.25.231.159
#traceroute to 172.25.231.159 (172.25.231.159), 30 hops max,
40 byte #packets

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

6 asa30-4 (172.25.231.159)(H!) 0.818 ms (H!) 0.770 ms

(H!) 0.760 ms

netstat -r liefert:

#192.168.1.0 \* 255.255.255.0 U 0 0 #0 eth1
#172.25.231.0 \* 255.255.255.0 U 0 0 #0 eth0
#default 172.25.231.1 0.0.0.0 UG 0 0 #0 eth0

Ich hoffe das hilft euch und mir, was ich nicht glaube, weil
alles eingestellt ist, wie route etc.

Das sagt mir zumindest zwei Dinge:

a) Du hängst mit eth0 am selben Netzwerk wie der unerreichbare Rechner

b) Mit dem Netzwerk liegt einiges im Argen, denn wegen a) geht die Verbindung über genau 0 Router, d.h. traceroute sollte keine 6 Hops ausgeben (tatsächlich sind es keine wirklichen Hops, sondern timeouts die als Hops interpretiert werden - folglich dürfte auch ping größere Paketverluste melden)

Unsystematische Paketverluste deuten meist auf ein Hardwareproblem hin. Probeweises Ersetzen von Netzwerkkarten und -kabel entlarvt den Schuldigen. Wenn die Rechner zu weit voneinander entfernt sind, um auf die Schnelle ein Patchkabel zu legen, musst Du halt einen der beiden zum anderen tragen.

genumi

Vielleicht ist irgendein Service aus oder soo???

Ich tippe auf netfilter. Gehe zu dem Rechner hin, betrachte die Ausgabe von

 # iptables-save

und denke darueber nach.

Gruss vom Frank.

> > #traceroute 172.25.231.159  
> > #traceroute to 172.25.231.159 (172.25.231.159), 30 hops max,  
> > 40 byte #packets  
> > # 1 \* \* \*  
> > # 2 \* \* \*  
> > # 3 \* \* \*  
> > # 4 \* \* \*  
> > # 5 \* \* \*  
> > # 6 asa30-4 (172.25.231.159)(H!) 0.818 ms (H!) 0.770 ms (H!) 0.760 ms

Das sagt mir zumindest zwei Dinge:

b) Mit dem Netzwerk liegt einiges im Argen, denn wegen a) geht
die Verbindung über genau 0 Router, d.h. traceroute sollte
keine 6 Hops ausgeben (tatsächlich sind es keine wirklichen
Hops, sondern timeouts die als Hops interpretiert werden -

Nein. traceroute erhoeht die TTL (pro Zeile) und versucht damit den naechsten Hop zum Ziel zu erreichen. Seltsamerweise passt hier max hops (30) nicht zu den 6 Versuchen und ausserdem behauptet der Rechner ja irgendwann von sich selbst host unreachable (und luegt damit offensichtlich). Sowas fabriziert eigentlich nur ein packet filter, evtl. auch auf dem switch dazwischen.

folglich dürfte auch ping größere Paketverluste melden)

Unsystematische Paketverluste deuten meist auf ein
Hardwareproblem hin. Probeweises Ersetzen von Netzwerkkarten
und -kabel entlarvt den Schuldigen.

Ich glaube nicht an ein Hardware-Problem.

Wenn die Rechner zu weit
voneinander entfernt sind, um auf die Schnelle ein Patchkabel
zu legen, musst Du halt einen der beiden zum anderen tragen.

Boah, wie fies!

Gruss vom Frank.

Ich weiß nicht, was ich da auslesen kann aus der Ausgabe???
Kannst du mir mehr darüber erzählen, weil es hilft gar nichts, ich hab schon gegoogelt, bis ich fast blau angelaufen bin!!!

Gruss!!

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

iptables-save

Ich weiß nicht, was ich da auslesen kann aus der Ausgabe???

Ist das eine Frage?

Kannst du mir mehr darüber erzählen, weil es hilft gar nichts,
ich hab schon gegoogelt, bis ich fast blau angelaufen bin!!!

http://iptables-tutorial.frozentux.net/iptables-tuto…

HTH,
Gruss vom Frank.

Hi…

b) Mit dem Netzwerk liegt einiges im Argen, denn wegen a) geht
die Verbindung über genau 0 Router, d.h. traceroute sollte
keine 6 Hops ausgeben (tatsächlich sind es keine wirklichen
Hops, sondern timeouts die als Hops interpretiert werden -

Nein. traceroute erhoeht die TTL (pro Zeile) und versucht
damit den naechsten Hop zum Ziel zu erreichen.

Genau. Und wenn mit TTL n lang genug keine Antwort kommt, nimmt traceroute an, der Router n sei vorhanden, antworte aber nicht, und probiert es weiter mit TTL n+1.

Nur in diesem Fall verschwinden die ersten 5 Pakete im Nirvana, auf das sechste kommt die Antowrt, die eigentlich schon beim ersten hätte kommen sollen - darum behauptet traceroute, es seien 6 Hops bis zum Zielrechnerim selben Subnetz…

Sowas fabriziert eigentlich nur ein packet filter, evtl. auch auf
dem switch dazwischen.

Ich glaube nicht an ein Hardware-Problem.

Ich kann mir keinen Filter vorstellen, der n identische Pakete verwirft und dann eins durchlässt… Ok, ja, ich könnte so einen Filter mit einer Zeile anlegen.
Besser formuliert: Ich kann mir keinen Admin vorstellen, der so einen Schwachsinn macht. Das beweist natürlich nicht, daß es ein Hardwareproblem ist, sondern ist wohl eher ein Hinweis auf meine mangelde Menschenkenntnis.

genumi