Für ein Projekt benötigte ich vier neue Linuxserver. Da sich die Konfiguration der vier Server sehr ähnelt, beschloss ich einen Server mit den benötigten Paketen zu installieren und den Server zu klonen und anschließend Servernamen und IP Adressen entsprechend anzupassen.

Da unsere Server mit Hilfe von ESXi 5.0 virtualisiert werden, konnte ich die VMDK-Datei des Servers einfach mit dem folgenden Kommando auf der ESXi Konsole klonen.

~ # vmkfstools -i /vmfs/volumes/vmfs/Servername-1/Servername-1.vmdk -d thin /vmfs/volumes/vmfs/Servername-2/Servername-2.vmdk

Die benötigten Server waren so allesamt schnell installiert und einsatzbereit. Lediglich der Server, der als DB-Slave der MySQL Datenbank arbeiten sollte, zeigte ein ungewöhnliches Verhalten. Dieser Server war aus irgendeinem Grund einzig und allein vom DB-Master Server aus per SSH erreichbar. Beim Verbindungsaufbau von jedem anderen Rechner aus gab es einen Timeout.

Es begann eine lange und zermürbende Fehlersuche. Ich habe DNS Namen aufgelöst (klappte super), Pings versendet (klappte genau so gut), nmap verwendet und mit meinem Kollegen mehrfach einen Blick in diverse Konfigurationsdateien geworfen. Alles ohne Ergebnis. Anscheinend mussten wir tiefer in die Trickkiste greifen.

Also Wireshark angeschmissen und Pakete gesnifft. Zuerst habe ich die Pakete einer funktionierenden SSH-Sitzung mitgesnifft, um den TCP-Verkehr einer funktionierenden Verbindung mit dem des Problemkandidaten vergleichen zu können. Anschließend habe ich mir den Verbindungsaufbau zu unserem Problemserver angesehen und stellt verwundert fest, dass hier bereits der initiale 3-Wege-Handshake der TCP-Verbindung scheitert. Also nochmal einen Blick in die iptables geworfen. Natürlich ohne etwas zu finden, was dieses Verhalten erklären könnte.

Da ich nach der erfolgten Fehlersuche bereits unter Betriebsblindheit litt und meine Kollegen nicht auch noch damit quälen wollte, postete ich mein Phänomen im Ubuntuusers Forum. Hier fand ich nette und hilfreiche Tipps und schließlich auch die Lösung des Problems.

Aber woran lag es denn nun?

Schuld war einzig und allein eine falsche Subnetzmaske. Während ich dabei war, auf einen Forenpost zu antworten und die benötigten Ausgaben in den Thread hackte, fiel mir bei der Ausgabe der Kernel-IP-Routingtabelle eine seltsame Subnetzmaske auf. Ein Blick in die Datei /etc/network/interfaces brachte schnell Gewissheit. Auf dem Interface war eine falsche Subnetzmaske konfiguriert. Nämlich nicht die von unseres LANs, sonder die unserer DMZ. Kaum war diese korrigiert, war auch das Problem mit der SSH-Verbindung behoben.

Obwohl ich während der Fehlersuche mehrfach in diese Datei geschaut habe, hab ich den Fehler zuerst nicht bemerkt. Aber manchmal sieht man halt den Wald vor lauter Bäumen nicht.

Daher möchte ich mich nochmal für die tolle Unterstützung der Ubuntuusers Community bedanken. Ohne sie hätte ich vielleicht noch sehr lange nach der Nadel im Heuhaufen gesucht.