Was wäre ein Computersystem ohne Netzwerk? Nicht einmal diese Seite könntest Du ohne Netzwerke sehen. Dementsprechend kommt es beim Aufbau oder der Erweiterung von IT-Systemen immer wieder zu Fehlern, weil irgendeine Netzwerk-Kommunikation nicht funktioniert.

In meiner Erfahrung kommt das ziemlich häufig vor. Und oftmals sind Anwendungsbetreuer oder Systemadministratoren damit konfrontiert, Fehler im Netzwerk suchen zu müssen. Daher zielt eine meiner Lieblingsfragen bei Vorstellungsgesprächen auf die strukturierte Fehlersuche im Netzwerk.

Im folgenden versuche ich, eine Anleitung dazu zu geben. Kenntnisse über TCP/IP, DNS etc. setze ich voraus. Gegebenenfalls findet sich dazu aber auch reichlich weiterführende Literatur im Internet.

Die Symptome

Die Symptome sind vielfältig: ein Popup sagt „Could not establish connection to…“, ein Log-Eintrag sagt „connection to … failed“ oder gar etwas kryptisches wie einfach nur eine Fehlernummer. Manche Fehlermeldungen sprechen auch konkret von einem „Timeout“, aber an welcher Stelle genau? Schließlich braucht es unter der Haube einige Schritte, bis eine Verbindung aufgebaut ist.

Die Diagnose

Hier will ich auf verschiedene Diagnoseschritte eingehen.

Log-Dateien

Der erste Blick sollte der Fehlermeldung selbst oder den Log-Dateien gelten. Mit etwas Glück finden sich hier schon konkrete Hinweise wie „could not resolve…“ (Hinweis auf DNS), „connection refused…“ (Gegenseite hört nicht). Diesen sollte nachgegangen werden.

Doch Vorsicht: ich habe auch schon die Fehlermeldung „could not ping…“ gesehen, die aber mit dem Ping, das wir aus der TCP/IP-Welt kennen, nichts zu tun hatte. In Wirklichkeit steckte dahinter eine TCP-Verbindung.

DNS

Üblicherweise werden DNS-Namen als Ziele verwendet anstatt IP-Adressen. Die können zum einen sprechender sein als eine Zahl. Zum anderen muß dann nur der DNS-Record aktualisiert werden, wenn ein System mal sein Adresse ändert. Es muß nicht gleich die neue Adresse überall aktualisiert werden, wo sie verwendet wird.

Versuche, den Namen mit nslookup aufzulösen, z.B. so:

hh@bert:~$ nslookup www.google.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	www.google.com
Address: 142.250.186.36
Name:	www.google.com
Address: 2a00:1450:4001:827::2004

Sollte das nicht funktionieren, gibt es verschiedene Ursachen, die Du überprüfen solltest:

• Wenn der DNS-Server eine negative Antwort gibt, kann der Name nicht aufgelöst werden. Dann kann z.B. der Name falsch sein, der Name ist nicht im DNS konfiguriert, oder die Weiterleitung innerhalb des DNS funktioniert nicht, und die Zone kann nicht erreicht werden.
• Kommt gar keine Antwort vom DNS-Server, kann dieser nicht erreicht werden. Dann ist zu prüfen, ob überhaupt der richtige DNS-Server konfiguriert ist, ob der DNS-Server verfügbar ist, und ob ggfs. eine Firewall das DNS blockiert.

TCP-Verbindungsaufbau

Für diesen Abschnitt ist es zweckmäßig, den TCP Three-Way Handshake verstanden zu haben.

Am besten öffnest Du zwei Shell-Fenster gleichzeitig. In dem einen lässt Du ein tcpdump laufen. Dafür brauchst Du root-Rechte, damit tcpdump das Interface in den Promiscuous-Mode setzen kann.

tcpdump -ni <Interface> host <Zieladresse>

Im anderen kannst Du einen Verbindungsversuch starten und beobachten, was im tcpdump passiert. Am einfachsten geht das mit

telnet <Zieladresse> <Zielport>

Beispiel:

hh@bert:~$ telnet www.google.com 80
Trying 142.250.186.36...
Connected to www.google.com.
Escape character is '^]'.

Manchmal wird telnet im Zuge von Sicherheitsrichtlinien entfernt. Dann geht immer noch

echo test >/dev/tcp/<Zieladresse>/<Zielport>

Beispiel:

hh@bert:~$ echo test >/dev/tcp/142.250.186.36/80
hh@bert:~$ 

Jetzt ist es Zeit, die Ausgabe von tcpdump auszuwerten. Das kann zum Beispiel so aussehen:

root@bert:~# tcpdump -ni enp0s31f6 host 142.250.186.36
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:41:00.486368 IP 192.168.29.2.54676 > 142.250.186.36.80: Flags [S], seq 3920404284, win 64240, options [mss 1460,sackOK,TS val 3009356487 ecr 0,nop,wscale 7], length 0
10:41:00.501129 IP 142.250.186.36.80 > 192.168.29.2.54676: Flags [S.], seq 2734096272, ack 3920404285, win 65535, options [mss 1412,sackOK,TS val 4062033570 ecr 3009356487,nop,wscale 8], length 0
10:41:00.501143 IP 192.168.29.2.54676 > 142.250.186.36.80: Flags [.], ack 1, win 502, options [nop,nop,TS val 3009356502 ecr 4062033570], length 0

Kein Syn

Fehlt schon das Syn-Paket (hier Zeitstempel 10:41:00.486368), dann betrachtest Du entweder das falsche Interface, oder das Quellsystem schickt erst gar keinen Verbindungsversuch ab. Dann brauchst Du an Firewalls und sonstiges nicht weiter denken, sondern kannst Dich auf Dein System konzentieren. Zu überprüfen sind lokale Firewall (iptables), lokales Routing (z.B. Default-Gateway) oder SELinux-Einstellungen.

Kein Syn-Ack

Geht das Syn-Paket raus, aber es kommt kein Syn-Ack-Paket zurück (hier Zeitstempel 10:41:00.486368), liegt ein Timeout vor. Du wirst auch sehen, daß das Syn-Paket wiederholt wird. Das ist so ziemlich das unspezifischste Ergebnis. Fehlerquellen kann es viele geben. Die häufigsten sind:

• Firewall blockiert/ist nicht freigeschaltet. Das ist am einfachsten zu überprüfen.
• Asymmetrisches Routing: die Antwort kommt auf einem anderen Weg zurück und wird durch Anti-Spoofing-Regeln oder lokale Einstellungen blockiert.
• Sicherheitssystem blockieren den Verkher, z.B. IPS, DDOS-Protection etc.

Zur weiteren Diagnose ist ein Blick auf das Zielsystem hilfreich, am besten wieder mit tcpdump: kommt das Syn-Paket an? Wenn nicht, ist schon der Hinweg blockiert. Geht das Syn-Ack-Paket raus? Wenn ja, ist der Rückweg blockiert.

Wenn nicht, ist der Fehler auf dem Zielsystem wie unten beschrieben zu suchen.

Reset

Antwortet das Ziel mit einem Reset wie in diesem Beispiel, dann ist der Port nicht offen.

root@bert:~# tcpdump -ni enp0s31f6 host 192.168.29.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:48:19.864215 IP 192.168.29.2.56742 > 192.168.29.1.2929: Flags [S], seq 385704738, win 64240, options [mss 1460,sackOK,TS val 1499059600 ecr 0,nop,wscale 7], length 0
10:48:19.865186 IP 192.168.29.1.2929 > 192.168.29.2.56742: Flags [R.], seq 0, ack 385704739, win 0, length 0

Auf dem Quellsystem sieht das dann so aus:

hh@bert:~$ telnet 192.168.29.1 2929
Trying 192.168.29.1...
telnet: Unable to connect to remote host: Connection refused

hh@bert:~$ echo test >/dev/tcp/192.168.29.1/2929
bash: connect: Connection refused
bash: /dev/tcp/192.168.29.1/2929: Connection refused

Dann ist die Zielseite zu überprüfen:

• Ist der Port offen? Das lässt sich mit netstat überprüfen.
• Läuft die Anwendung? Hat sie es nicht geschafft, den Port zu öffnen?
• Kommt das Reset von einer lokalen Firewall oder SELinux?

Tipps zur schnelleren Diagnose

Im vorangegangenen wurden einige eher spezielle Fehlerquellen benannt. Manchmal muß man auch entsprechend tief einsteigen. Die gängigsten fehler lassen sich aber ziemlich schnell überprüfen, und mit etwas Glück bist Du dann schon am Ziel.

1. nslookup <Zielname>
2. echo test >/dev/tcp/<Zieladresse>/<Zielport>
   • Reset -> Fehler im Zielsystem suchen
   • Timeout -> Fehler im Quellsystem suchen (netstat), ansonsten unterwegs (z.B. Firewall)

UDP-Verbindungsaufbau

Das klingt angesichts des verbindungslosen Charakters von UDP etwas paradox. Doch viele Anwendungen bauen ihr eigen Sicherungsschicht auf UDP auf und kennen dann doch wieder so etwas wie Verbindungen.

Vieles von dem für TCP gesagten lässt sich nicht übertragen. Wirklich diagnostiziert werden kann hier nur mit tcpdump auf Quell- und Zielsystem:

• Sehe ich das Paket auf der Quelle rausgehen?
• Sehe ich das Paket im Ziel ankommen?

Fazit

Beim Schreiben dieses Artikels habe ich gemerkt, daß es gar nicht so einfach ist, das Thema mit allen Abzweigen strukturiert darzustellen. Ich hoffe, der Beitrag ist trotzdem nützlich. Für Verbesserungsvorschläge bin ich dankbar.