SSH Verbindung - Server zu Server funktioniert nicht mehr

[caomhan]

Hallo Debian Freunde,

ich habe einen Hetzner Server und einen Büro Server.
Auf beiden Debian Squeeze mit nahezu indentischer Installation.

Server A: Hetzner Online Server
Server B: Server im Büro

Von meinem Arbeitsgerät (iMac) kann ich problemlos zu beiden Servern via SSH verbinden.
Von Server B kann ich allerings nicht via SSH mit Server A kommunizieren.

Warum: Keine Idee, nicht mal einen Anhaltspunkt.
Wenn ich meine FritzBox neu starte, funktioniert es sporadisch innerhalb 5 Minuten.
An der Fritz Box kann es aber ja eigentlich nicht liegen, da ich von meinem iMac ebenso ganz normal via SSH auf Server A komme.

Fail2Ban auf Server A kann auch ausgeschlossen werden, da ich ja wie erwähnt mit dem iMac (gleiche IP) auf Server A komme.

Es muss also definitiv an Server B liegen.

Fehlermeldungen:
Server A zeigt ab und zu ein "session opened" und darauf ein "session closed", jedoch auch nicht immer - vielleicht versucht sich durch zufall ja auch nur jemand "einzuhacken".
Server B zeigt beim Verbindungsversuch "Network unreachable", via Ping funktioniert die Verbindung aber.

Ich hab "no Idea", vielleicht ihr?

[Cae]

Code: Alles auswählen

ssh -v user@host

liefert welche weitergehenden Details? Vom Client zum Server, wo es nicht klappt.

Gruß Cae

[caomhan]

Von Server B auf Server A (umgekehrt geht übrigens auch wunderbar):

Code: Alles auswählen

OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to s2.xxxxxxxxxxx.de [xxxxxxxxxxx] port 22.
debug1: connect to address xxxxxxxxxxx port 22: Connection timed out
debug1: Connecting to s2.xxxxxxxxxxx.de [xxxxxxxxxxxIPV6] port 22.
debug1: connect to address xxxxxxxxxxxIPV6 port 22: Network is unreachable
ssh: connect to host s2.xxxxxxxxxxx.de port 22: Network is unreachable

[FANA]

Code: Alles auswählen

nc -z <IP-Server A> 22
echo $?

Wenn keine 0 als Ausgabe kommt, erreichst du den SSH Server nicht.

Network is unreachable

Wie sieht es mit den Routen auf der Kiste aus? Was sagt ein

Code: Alles auswählen

 traceroute <IP Server A>

bzw.

Code: Alles auswählen

mtr -n <IP Server A>

?

[Gunman1982]

Auch mal schaun wie das mit firewalls/routers und etwaige masquerade geschichten aussieht.

[caomhan]

Danke für eure Antworten.
Also:

Code: Alles auswählen

nc -z <IP-Server A> 22
echo $?

Hat erst eine 1 gebracht, danach nur 0.

Auf ein traceroute hätte ich ja auch mal kommen können
Das Ergebnis muss ich euch später mitteilen, da es aktuell wieder sporadisch geht.

Gerade ging es wieder nicht. traceroute ausgeführt: Ging langsam aber sicher durch.
Danach auch SSH wieder. Werde es gleich nochmals testen.

Generell schon mal zum Traceroute: Diese 3 Positionen dauern ungewöhnlich langsam. Davor kommt nur meine FritzBox und der Einwahlpunkt(?) und danach kommt schon Hetzner. Nur diese 3 Punkte dauern zusammen ca. 20 Sekunden:

Code: Alles auswählen

 3  88.79.18.181 (88.79.18.181)  60.738 ms  61.599 ms  62.116 ms
 4  92.79.212.193 (92.79.212.193)  34.161 ms  34.195 ms  37.303 ms
 5  92.79.213.122 (92.79.213.122)  44.176 ms  45.649 ms  45.673 ms

[caomhan]

Okay, jetzt wieder: Klare Sache.
Er hängt nach Position 2:

Code: Alles auswählen

 1  fritz.box (192.168.2.1)  0.960 ms  1.952 ms  1.951 ms
 2  dslb-0xx-0xx-0x0-00x.pools.arcor-ip.net (xx.xx.xx.x)  32.354 ms  32.359 ms  32.353 ms

Worauf lässt das schließen?
An der Stelle ist er ja schon "aus dem Büro" raus ?

[FANA]

Hm, könnte eine zu große MTU sein, sodass Pakete an manchen Routern auf der Strecke stecken bleiben.

http://www.elektronik-kompendium.de/sit ... 812211.htm ( s. "Beispiel: Ein bestimmter Server ist nicht erreichbar" )

[caomhan]

Mhh. also ich sag mal so: Ich habe nichts geändert Vor einem Update (apt-get upgrade - könnte in den Logs schauen, welche Pakete das waren) lief alles wunderbar würde ich schätzen. Bin mir aber nicht sicher, dass es wirklich erst nach einem Update aufgetreten ist.

Werde mal in die Upgrade Log schauen.

MTU: Ping und weiteres funktioniert ja, scheinbar macht nur der SSH Dienst Probleme.
"ICMP-Pakete" -> Werde ich dennoch einmal kontrollieren, danke!

Aber schon mal herzlichen Dank an alle für die Beteiligung an der Problemlösung

Hier zwei Auszüge. Aber davon wird wohl nichts dafür verantwortlich sein.

Code: Alles auswählen

Start-Date: 2012-05-03  13:58:13
Commandline: apt-get install libpcre3 libpcre3-dev
Install: libpcrecpp0:amd64 (8.02-1.1, automatic), libpcre3-dev:amd64 (8.02-1.1)
End-Date: 2012-05-03  13:58:19

Start-Date: 2012-04-17  16:35:56
Commandline: apt-get upgrade
Upgrade: libarchive1:amd64 (2.8.4-1+squeeze1, 2.8.4.forreal-1+squeeze2), linux-image-2.6.32-5-amd64:amd64 (2.6.32-41, 2.6.32-41squeeze2), libmagickcore3:amd64 (6.6.0.4-3, 6.6.0.4-3+squeeze1), mysql-server:amd64 (5.1.49-3, 5.1.61-0+squeeze1), libmagickwand3:amd64 (6.6.0.4-3, 6.6.0.4-3+squeeze1), at:amd64 (3.1.12-1, 3.1.12-1+squeeze1), libgnutls26:amd64 (2.8.6-1+squeeze1, 2.8.6-1+squeeze2), mysql-server-core-5.1:amd64 (5.1.49-3, 5.1.61-0+squeeze1), apache2-mpm-prefork:amd64 (2.2.16-6+squeeze6, 2.2.16-6+squeeze7), libtasn1-3:amd64 (2.7-1, 2.7-1+squeeze+1), libfreetype6:amd64 (2.4.2-2.1+squeeze3, 2.4.2-2.1+squeeze4), libmysqlclient16:amd64 (5.1.49-3, 5.1.61-0+squeeze1), apache2-utils:amd64 (2.2.16-6+squeeze6, 2.2.16-6+squeeze7), apache2:amd64 (2.2.16-6+squeeze6, 2.2.16-6+squeeze7), apache2.2-common:amd64 (2.2.16-6+squeeze6, 2.2.16-6+squeeze7), libcurl3:amd64 (7.21.0-2.1+squeeze1, 7.21.0-2.1+squeeze2), linux-base:amd64 (2.6.32-41, 2.6.32-41squeeze2), apache2.2-bin:amd64 (2.2.16-6+squeeze6, 2.2.16-6+squeeze7), libtasn1-3-dev:amd64 (2.7-1, 2.7-1+squeeze+1), libxml2:amd64 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), file:amd64 (5.04-5, 5.04-5+squeeze1), libxml2-dev:amd64 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libtiff4:amd64 (3.9.4-5+squeeze3, 3.9.4-5+squeeze4), libpng12-0:amd64 (1.2.44-1+squeeze2, 1.2.44-1+squeeze4), libpq5:amd64 (8.4.10-0squeeze1, 8.4.11-0squeeze1), imagemagick:amd64 (6.6.0.4-3, 6.6.0.4-3+squeeze1), libmagickcore3-extra:amd64 (6.6.0.4-3, 6.6.0.4-3+squeeze1), libcurl3-gnutls:amd64 (7.21.0-2.1+squeeze1, 7.21.0-2.1+squeeze2), linux-libc-dev:amd64 (2.6.32-41, 2.6.32-41squeeze2), libgnutls-dev:amd64 (2.8.6-1+squeeze1, 2.8.6-1+squeeze2), mysql-common:amd64 (5.1.49-3, 5.1.61-0+squeeze1), mysql-server-5.1:amd64 (5.1.49-3, 5.1.61-0+squeeze1), mysql-client-5.1:amd64 (5.1.49-3, 5.1.61-0+squeeze1), libmagic1:amd64 (5.04-5, 5.04-5+squeeze1)
End-Date: 2012-04-17  16:37:07

Naja, jetzt klappts auch wieder.
Warten wir erst mal bis morgen ab - in der "Hoffnung", dass es dann nicht mehr geht.

Schönen Abend!

*Update*
Gerade funktionierte es wieder nicht. ich habe auf Server A gerade auch IMCP Pakete in iptables erlaubt. Das sollte schon mal gehen. MTU von Server B liegt dennoch bei 1500, oder muss/sollte ich den auch anpassen? Über IMCP sollte das doch jetzt geregelt werden, oder?

Also wie gesagt: Gerade klappte es wieder nicht. Dann ein Traceroute der bei Post 3, 4 und 5 wieder sehr langsam ist und danach funktioniert auch der SSH Zugriff. Sozusagen stellt der Traceroute die Verbindung wieder her. SSH Zugriff ist, wenn er denn wieder klappt, übrigens auch normal schnell. Wahrscheinlich ist 1&1 irgendwie dafür verantwortlich und ich mach mich hier bekloppt.

[Gunman1982]

MTU: Ping und weiteres funktioniert ja, scheinbar macht nur der SSH Dienst Probleme.
"ICMP-Pakete" -> Werde ich dennoch einmal kontrollieren, danke!

Dir ist bewusst das ein Ping Paket (ICMP ECHO_REQUEST) mit den 56byte weit unter der MTU Grenze von DSL ~1464byte liegt oder? Kannst also nicht sagen MTU ist passend weil Ping geht.

[caomhan]

MTU: Ping und weiteres funktioniert ja, scheinbar macht nur der SSH Dienst Probleme.
"ICMP-Pakete" -> Werde ich dennoch einmal kontrollieren, danke!

Dir ist bewusst das ein Ping Paket (ICMP ECHO_REQUEST) mit den 56byte weit unter der MTU Grenze von DSL ~1464byte liegt oder? Kannst also nicht sagen MTU ist passend weil Ping geht.

Okay, was ist dann mit "ping -s 2048 SERVER A"? Oder verstehe ich das falsch?

Habe jetzt MTR einmal getestet. Keine Probleme auch bei vielen Druchgängen nicht. Via SSH zwischenzeitlich nicht erreichbar, MTR zeigt keine Probleme. Nur der Traceroute hat die SSH Verbindung mal wieder "in Gang geworfen". Sehr strange..

Mache ich ein "ssh -v root@...." bleibt er so lange bei Connection hängen, bis der Traceroute die 3. Position geschafft hat, danach fluppt es. (Update: Ging gerade auch nicht mehr)

Könnte es am Bonding der Netzwerkkarten liegen? Eher auch nicht, oder? Intern klappt ja beim Traceroute alles flott und gab ja auch vorher keine Probleme damit.

[caomhan]

Ich habe nun folgende gemacht:

Server A (Hetzner Server) folgende iptable Rules:

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             localhost           icmp echo-reply state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  localhost            anywhere            icmp echo-request state NEW,RELATED,ESTABLISHED 
...

Server B (Büro Server) folgende iptable Rules:

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             localhost           icmp echo-request state NEW,RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  localhost            anywhere            icmp echo-request state NEW,RELATED,ESTABLISHED 
...

Beim Büro Server die MTU von bond0 auf 1412 gesetzt. eth0 und eth1 wurden auch automatisch updated und haben auch MTU 1412. Logisch.

Die Verbindung klappt gerade nicht, ein Traceroute bringt mich nicht weiter, denn danach klappt es ja für X Minuten.
IMCP und MTU 1412 hilft mir also leider nicht.

[caomhan]

Ich habe heute einmal openssh-server neu installiert. Leider keine Besserung.
Aber jetzt mal etwas Anderes:

Wenn ich von Server B nicht auf Server A, aber von Server B zur gleichen Zeit auf einen dritten Server zum Password Prompt komme, liegt es dann nicht eher wahrscheinlich an Server A?

Anders herum: von iMac zu Server A: Gleiche Leitung, gleiche IP, gleiche MTU, andere OpenSSH Version (klappt immer)

OpenSSH Version iMac (funktioniert immer tadellos):

Code: Alles auswählen

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011

OpenSSH Version Server A & Server B:

Code: Alles auswählen

OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010

Aber daran sollte es auch nicht liegen.

Tja, so komme ich leider nicht weiter.
Hat noch jemand eine Idee / die gloreiche Idee?

Viele Grüße,
caom


Update:

Jetzt bin ich wieder anderer Meinung: Es muss an Server B liegen. Sorry!
Ein traceroute vom iMac geht super flott durch.
Der traceroute von Server B hängt ja ewig bei Pos 3, 4 und 5.

Jetzt nur die Frage: Warum ?

Update:

Hier einmal die Netzwerk-Settings: (Bonding hatte ich auch bereits einmal ausgeschaltet, keine Änderung):

Code: Alles auswählen

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
	address 192.168.2.10 
	netmask 255.255.255.0
	network 192.168.2.0
	broadcast 192.168.2.255
	gateway 192.168.2.1
	dns-nameservers 192.168.2.1
	slaves eth1 eth0
	bond_mode 2
	bond_miimon 100
	bond_updelay 200
	bond_downdelay 200

192.168.2.1 = FritzBox
192.168.2.10 = Server B