Administrators Toolbox: Netcat (nc/ncat) Debugging mit der TCP/IP Swiss Army Knife

Manchmal begegnen einer Administrator:in Probleme oder Aufgaben, die es erfordern auf einem relativ niedrigen Level Netzwerkverbindungen umzuleiten, umzuformen oder auch nur zu testen. Sehr praktisch und oft völlig ausreichend sind hier netcat (nc) und ncat, die typischerweise auf den gängigen Unixen paketiert oder schon vorinstalliert sind. Am besten illustieren ein paar Beispiele die Möglichkeiten: Einseitige Erreichbarkeitsprüfung Eine der häufigsten Fragestellung die bei Einrichtung oder Debuggen von Systemen entstehen ist typischerweise “Kann ich von hier eine Verbindung zu diesem Port öffnen und lauscht dort irgendetwas?” Dies lässt sich hier auch sehr leicht abbilden: user@alice $ nc -zv berta 1233 nc: connect to 192.0.2.1 port 1234 (tcp) failed: Connection refused user@alice $ nc -zv berta 1234 Connection to 192.0.2.1 1234 port [tcp/*] succeeded! In diesem Beispiel sind zwei Verbindungstests zu sehen, einmal erfolgreich, das andere Mal nicht. Die Option -z ändert das Verhalten von nc, es wird lediglich eine TCP-Verbindung auf- und wieder abgebaut, jedoch keine Daten übertragen. Die Option -v erhöht die “Verbosity”, also die Gesprächigkeit, um auch im Falle des Scheiterns eine Nachricht auszugeben. Durchgängigkeitsprüfung zwischen zwei Maschinen Gerade beim Einrichten von neuen Anwendungen oder ganz generell Änderungen in komplexen Netzwerken, ist es nicht offensichtlich ob von einem bestimmten Endpunkt zu einem anderen eine Netzwerkverbindung aufgebaut werden kann. Oftmals sind verschiedene Firewalls im Weg, ein besonderer Spass, falls die Netzwerkadministrator:innen als Standardeinstellung “DROP” statt “REJECT” gewählt haben und schlicht einfach keine Antwort kommt. Dazu hier ein Beispiel, es gibt die Maschinen alice und berta, und der Port 1234 (TCP) auf berta sollte von alice erreichbar sind. Diese kann man sehr einfach prüfen. Dazu muss der Port 1234 (TCP) natürlich unbenutzt sein, ansonsten kommt hier die Fehlermeldung nc: Address already in use. Dazu auf berta: user@berta $ nc -l 1234 um auf dem Port 1234 TCP-Verbindungen anzunehmen. Dann auf alice: user@alice $ echo test | nc berta 1234 wobei “berta” hier eine IP-Addresse oder ein auflösbarer Name sein kann. Falls alles in Ordnung ist, sollte auf berta ein “test” angekommen sein. echo test gibt einfach den String “test” auf stdout aus, der durch die Pipe | auf stdin von nc durchgereicht wird. nc schickt per default die Eingabe von stdin dann über die Verbindung. Dann sollte es auf berta so ausehen: user@berta $ nc -l 1234 test Falls die Verbindung abgewiesen wird (REJECT), sieht das folgendermassen aus: user@alice $ echo test | nc berta 1234 user@alice $ echo $? 1 Das ganze lässt sich auch umgekehrt handhaben: user@berta $ echo test | nc -l 1234 user@alice $ nc berta 1234 test und mit UDP: user@berta $ echo "Jetzt mit UDP" | nc -l 1234 -u user@alice $ nc -u berta 1234 Jetzt mit UDP Das ist fürs Testen / Fehler finden schon mal nicht schlecht (es gibt noch diverse Optionen um das Netzwerkverhalten zu ändern, falls notwendig), aber damit sind die Möglichkeiten noch nicht ausgeschöpft. Dateitransfer In den obigen Beispielen wurde nur ein kurzer Text transportiert, aber dieser ist auch austauschbar. So lässt sich ziemlich leicht der Dateitransfer zwischen zwei Maschinen orchestrieren. user@berta $ nc -l 1234 > ziel.iso user@alice $ nc -N berta 1234 < quelle.iso Die Option -N bewirkt das Schliessen der Verbindung nach Ende des Inputs. Das Ganze kann man mit pv oder ähnlichen Werkzeugen mit Fortschrittsbalken ausstatten, falls gewünscht. user@berta $ nc -l 1234 > ziel.iso user@alice $ pv quelle.iso | nc -N berta 1234 627MiB 0:00:00 [2.69GiB/s] [=============================================>] 100% aber wie sieht das mit mehreren Dateien und Ordnerstrukturen aus? user@alice $ tree ncat_test ncat_test ├── a │ ├── fileA │ └── fileB ├── b └── c 4 directories, 2 files user@alice $ tar -cz ncat_test | nc -N berta 1234 user@berta $ nc -l 1234 | tar -xz user@berta $ tree . └── ncat_test ├── a │ ├── fileA │ └── fileB ├── b └── c 5 directories, 2 files Soweit, so sinnvoll. Kommunikation zwischen zwei Maschinen ist damit schon zu guten Teilen abgedeckt, aber wie schaut es mit der zwischenmenschlichen Kommunikation aus? ncat Features Die ncat-Implementation enthält neben den Basisfähigkeiten von nc auch verschiedene weitergehende Möglichkeiten. Eine davon ist tatsächlich ein Gruppenchat! Vorbei sind die Zeiten der überteuerten und überladenen Chattools mit 300MB-“Clients” (also einem Browser der nur eine einzige Website anzeigt), vorbei die animierten Emojis und so weiter. Es geht schliesslich viel einfacher. chats mit ncat Alice startet im Folgenden einen Chatserver und verbindet sich von einem anderen Terminal dann. Ihr folgen Berta und Charli. user@alice $ ncat -l 1234 --chat user@alice $ nc alice 1234 <announce> ::1 is connected as <user5>. <announce> already connected: nobody. user@berta $ ncat alice 1234 <announce> 192.168.252.6 is connected as <user6>. <announce> already connected: ::1 as <user5>. user@charli $ ncat alice 1234 <announce> 192.168.252.7 is connected as <user7>. <announce> already connected: ::1 as <user5>, 192.168.252.6 as <user6>. Danach werden alle Nachrichten einfach an alle (bis auf die Sender:in) versendet. Aber damit sind wir natürlich noch nicht fertig, das letzte Beispiel kommt mit einer Debugging-Anekdote. TLS auspacken Bei einem Kunden war Icinga 2 im Einsatz und InfluxDB2 als Speicher für Performance-Daten, jedoch waren in den entstehenden Graphen im Grafana teilweise Lücken an denen Daten hätten stehen sollen. Zusätzlich waren den Log-Dateien von Icinga 2 (/var/log/icinga2/icinga2.log) Fehlermeldungen darüber, dass Probleme beim Schreiben von Performancedaten auftraten: [2024-06-07 10:37:59 +0200] warning/Influxdb2Writer: Unexpected response code: Bad Request [2024-06-07 10:37:59 +0200] warning/Influxdb2Writer: Unexpected Content-Type: application/json; charset=utf-8 Teilweise war hier ein bestimmter Service angegeben, in dessen Kontext das fehlschlagen würde. Da sowohl die Lücken als auch die Fehlermeldungen im Kontext der InfluxDB2-Verbindung standen, war es naheliegend, dass diese auch in Verbindung stehen würden. Die Lücken waren in viel mehr Services vorhanden, als es Fehlermeldungen gab und es waren auch bei weitem nicht diesselben. Die zuerst offensichtliche Kausalität schien nach einiger Betrachtung erstmal nicht mehr so offensichtlich. Weitere Details waren also notwendig. Das InfluxDB Line Protocol ist im Kern nur eine Aneinanderreihung von Zeilen und per se recht lesbar, die Daten werden über HTTP übertragen, also ist die Analyse ohne spezielle Werkzeuge an sich gut möglich. Die Fehlermeldungen in der Log-Datei wiesen auf eine Fehlermeldung von InfluxDB hin, jedoch fehlt hier der HTTP-Body in dem diese stehen würden! Nun gut, der nächste Schritt war dann die Idee, die Unterhaltung zwischen Icinga 2 und InfluxDB2 zu belauschen um sowohl die (fehlerhaften) Daten als auch die Fehlermeldungen mitlesen zu können. Die würde sich ja relativ einfach per tcpdump erledigen lassen, jedoch waren dann zwei weitere Steine im Weg:tcpdump war auf dem System nicht installiert und es hätte einen gewissen administrativen Aufwand und Zeit nach sich gezogen um das zu ändern. Das andere Problem war, dass die Verbindung über TLS übertragen wurden und der Mitschnitt somit unleserlich war! Die TLS-Übertragung abzuschalten wäre im Konflikt mit Richtlinien gestanden und war damit erstmal keine Option. Eine verbleibende Option war damit, einen lokalen Proxy zu errichten, die Verbindung von Icinga 2 dahin ohne TLS zu machen und dann den Proxy über TLS mit InfluxDB2 reden zu lassen. Der Proxy schreibt dann den kompletten Datenverkehr mit. Praktischerweise ist dies mit ncat einfach umzusetzen: # ncat -l 8086 --output conntrack.file --sh-exec "ncat --ssl influxdb-host 8086" Der Parameter --output conntrack.file schreibt den Datenverkehr in die Datei conntrack.file, --sh-exec "ncat --ssl influxdb-host 8086" startet ein zweites ncat und verbindet den stdout des ersten ncat mit dem stdin des zweiten und den stdout des zweiten mit dem stdin des ersten, womit eine bidirektionale Übertraung ermöglicht wird. Der Parameter --ssl startet eine TLS-Session zum Ziel. In Summe werden damit lokal auf Port 8086/TCP Verbindungen angenommen und die Daten sowohl über TLS an influxdb-host auf Port 8086/TCP weitergeleitet, als auch in die Datei conntrack.file geschrieben. Erkenntnise Das Sichten des dadurch entstandenen Mitschnitts brachte dann auch die Erkenntnise, zum Einen die Fehlermeldung von InfluxDB2, dass der Datensatz invalide Daten enthielt und auch die entsprechenden Daten. In diesem Fall waren es Zahlenwerte wie prometheus-query,hostname=foobar,service=foobar-cpu-requests,metric=blafoo value=-inf 1717686440 und dem schnellen Leser dürfte hier aufgefallen sein, dass hier der eigentliche Zahlenwert value mit -inf angegeben ist, also grob “negativ unendlich”. InfluxDB2 verweigert diesen Wert, berechtigterweise, und Icinga 2 bekommt eine Fehlermeldung und verwirft dann ALLE Datenpunkte, die hier gesendet wurden. Aus Performancegründen werden die Datenpunkte nicht einzeln übertragen, sondern gebündelt (Batch-Verfahren). Im Fehlerfall wird damit ein ganzer Block verworfen, also auch eine große Zahl (bis zu 1023 mit den Standardeinstellungen), was die Ursache für Lücken in anderen Graphen war. Aus diesen Erkenntnissen entstand dann das Issue #10073 und der Pull Request #10077 bei Icinga 2. Zusätzlich wurde der Pull Request #116 in der Bibliothek go-check entwickelt, die als Grundlage von check_prometheus dient, dem Monitoring Plugin, welches den fehlerhaften Datenpunkt erzeugte. Fazit Abschliessend bleibt nur noch allen zu danken, die an diesen netcat-Implementationen mitgearbeitet haben. Ohne diese Werkzeuge wäre es noch um einiges umständlicher solche Probleme zu analysieren oder generell mit Netzwerken zu arbeiten. Sie sind überall verfügbar, leichtgewichtig und vergleichsweise simpel zu benutzen und leicht mit anderen kombinierbar, in Summe: einfach gute Werkzeuge. Und das ist etwas, was ich nicht über viele Software sagen möchte. Ich hoffe, dass dieser kleine Ausflug ein paar Leser:innen ein wenig weiterbringt. Feedback, Kritik und Korrekturen sind generell willkommen. Wenn ihr noch Fragen zum netcat oder Debugging in Netzwerken habt, dann schaut euch unser MyEngineer Angebot an, ein Outsourcing für Linux und Open Source bei dem wir euch rund um das Thema unterstützen. Happy Hacking! Lorenz Kästle Systems Engineer Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang. Read more from Lorenz and meet the Team Der Beitrag Administrators Toolbox: Netcat (nc/ncat) Debugging mit der TCP/IP Swiss Army Knife erschien zuerst auf NETWAYS Blog.

Netz: Lösungen für Monitoring, Automatisierung, Hosting in Deutschland - NETWAYS
Aktualisiert: 30.8.2024

zum Artikel gehen

Administrators Toolbox: Netcat (nc/ncat) Debugging mit der TCP/IP Swiss Army Knife

WordPress Logs! Erfolgreiches Debugging WordPress-Fehlerprotokolle verständlich erklärt.

Unternehmens- und Produktvorstellung auf der SWISS BAU 2018 in BASEL (CH)

Swiss-U.S. Data Transfers: New Framework solves Privacy Hassles, finally!

Die Micro Swiss Nozzle Review und Montage

BigQuery Toolbox