Fehlersuche statt Raten

Bei der Fehlersuche in einem Netzwerk geht es nicht darum, mehr Befehle zu kennen. Es geht darum, Vermutungen durch eine Abfolge von Fragen zu ersetzen, deren Antworten nicht bestreitbar sind. Die Methode hat drei Regeln. Beginne mit der Pruefung, die am wenigsten Zeit kostet und am meisten ausschliesst. Aendere immer genau eine Sache auf einmal. Und frage nach jedem Test, was das Ergebnis beweist und was es nicht beweist — ein Test, der aus zwei verschiedenen Gruenden haette bestehen koennen, hat dir nichts gesagt.

Das Billigste zuerst heisst: Bevor du eine Konfiguration anfasst, frage, ob die Sache von hier ueberhaupt funktioniert und ob sie von woanders aus funktioniert. Zwei Blickpunkte zu vergleichen kostet einen Befehl und halbiert den Problemraum. Den Nutzer zu bitten, ein anderes Netzwerk zu versuchen, oder dieselbe Anfrage von einem anderen Rechner aus auszufuehren, ist meist mehr wert als eine Stunde Log-Lektuere.

Die Leiter der Fragen, von unten her: Hat der Rechner ueberhaupt eine Adresse und eine Default-Route? Loest der Name zu einer Adresse auf? Antwortet die Adresse auf der IP-Ebene? Ist der Port offen, und antwortet der Dienst darauf? Liefert die Anwendung eine korrekte Antwort? Jede Frage wird von einem anderen Werkzeug beantwortet, und jede Antwort grenzt den Verdaechtigen weiter ein, bis nur noch eine Schicht uebrig bleibt. Der Sinn der Leiter ist, dass sie irgendwann endet: Eine gute Fehlersuche verkleinert die Menge der moeglichen Ursachen, statt sie zu vergroessern.

Jedes Werkzeug beweist etwas Enges, und wer es fuer mehr als das haelt, kommt zu falschen Schluessen. ping beweist, dass ein Host auf ICMP antwortet und dass ein Pfad in beide Richtungen existiert; es beweist nicht, dass ein Webserver laeuft. dig beweist, was ein Resolver geantwortet hat und wie lange die Antwort zwischengespeichert wird; es beweist nicht, dass die Adresse erreichbar ist. curl beweist, was der gesamte Stack fuer eine konkrete Anfrage tut; es beweist nicht, dass andere Clients dieselbe Antwort erhalten. ss beweist, was auf dieser Maschine tatsaechlich lauscht und auf welcher Adresse; es beweist nicht, dass eine Firewall jemanden hereinlaesst.

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org @1.1.1.1 +short
203.0.113.7

$ dig api.example.org @8.8.8.8 +short
203.0.113.7Zwei Resolver, zwei verschiedene Antworten — ein Cache und ein veralteter Record, kein kaputtes Netzwerk.

$ curl -v https://api.example.org/health
*   Trying 198.51.100.20:443...
* connect to 198.51.100.20 port 443 failed: Connection timed out
* Failed to connect to api.example.org port 443: Connection timed out

$ curl -sv https://api.example.org/health -o /dev/null
*   Trying 93.184.216.34:443...
* Connected to api.example.org (93.184.216.34) port 443
* Server certificate: CN=*.example.org
< HTTP/2 200
< content-type: application/jsonDerselbe Befehl mit einem Timeout auf dem Port und mit der Adresse, die tatsaechlich funktioniert.

ss verdient besondere Aufmerksamkeit, weil es zwei Fehler trennt, die von aussen identisch aussehen: Es lauscht nichts, oder es lauscht etwas, aber nur auf der Loopback-Adresse. Ein Server, der an 127.0.0.1 gebunden ist, nimmt Verbindungen von derselben Maschine an und lehnt jede Verbindung von aussen ab, egal was die Firewall sagt. Genau diese eine Unterscheidung erklaert einen grossen Teil der Faelle, in denen der Dienst lokal funktioniert und von ueberall sonst nicht erreichbar ist.

$ ss -tlnp
State   Local Address:Port   Process
LISTEN  127.0.0.1:8080       users:(("node",pid=4127,fd=21))
LISTEN  0.0.0.0:22           users:(("sshd",pid=880,fd=3))

$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/
200Ein Dienst ist aus dem Netzwerk erreichbar, der andere nur von dieser Maschine.