Sockets, Sockets, Sockets

Wenn es darum geht Information über aktive Sockets in Linux Systemen anzuzeigen, sind netstat und ss zwei verbreitete Begriffe. Linux beinhaltet eine enorme Anzahl an Tools, um fast jedem Bedürfnis zu begegnen. Was das bedeutet? Das du deine Aufgabe unter Linux garantiert erledigt bekommst. Du musst es nur wollen! Einer der Tools die jeder Linux Admin kennt und zu seinem Standardrepertoire zählt, ist netstat. Netstat war lange Zeit das Standard Diagnose-Werkzeug um offene Ports, TCP, UDP, Routing Tables und vieles mehr auszulesen. Netstat ist wie die anderen Networking Programme: arp, ifconfig, iptunnel, nameif, und route im net-tools Paket paket enthalten, welches über Jahre hinweg nicht betreut und weiterentwickelt wurde. Für all diese Networking Tools existieren mittlerweile verbesserte Neuentwicklungen, zusammengefasst in der neuen iproute2 Suite. Darin enthalten ist unter anderem auch ss, als Alternative zu netstat gilt ss als die genauere und modernere Variante zum auslesen von Netzwerkstatistiken.

In diesem Artikel werde ich beide Tools genauer beleuchten und dir zeigen, warum du das Eine über das Andere wählen solltest (falls das denn so sein sollte ;)). Im Anschluss daran zeige ich noch, wie du mit ss auf einfache Weise Informationen darüber erhältst, was auf deiner Linux-Maschine und im Netzwerk vor sich geht.

Warum sollte ich mir um Sockets Gedanken machen?

Der Hauptgrund ist Fehlerbehebung. Mit beiden Tools ist es möglich detaillierte Informationen darüber zu bekommen, wie deine Linux Maschine mit anderen Maschinen kommuniziert. Wenn du häufiger mit Linux zu tun hast, werden dich folgende Fragen früher oder später einmal genauer interessieren:

• Auf welchen Ports laufen meine Prozesse?
• Lauscht mein Serverprozess auf dem Port, wo er eigentlich lauschen soll?
• Läuft der Prozess auf dem Loopback Network (127.0.0.1) bzw ::1?

Solche und weitere Fragen, rund um Netzwerkstatistiken und die allgemeinen Zustände deiner Sockets lassen sich, mit den beiden Command-line Tools ss und netstat, beantworten.

Doch wie kommen die beiden Tools an diese Information? In den nächsten Abschnitten kläre ich diese Frage mit dir auf. Die folgenden zwei “Konzepte” spielen dabei eine wichtige Rolle.

Procfs

Eine Quelle für Informationen ist proc oder procfs. Procfs kann man sich wie ein Pseudo-Dateisystem vorstellen, welches im Speicher vorgehalten wird. Es speichert Daten über alle laufenden Prozesse, während es den Anschein macht Datein zu beinhalten, aber eigentlich gar keine beinhaltet. Erreichbar über /proc, kannst du direkt von hier aus Prozessinformation, inklusive der dazugehörigen PIDs, mit cat abrufen. TCP und UDP Socket Informationen finden sich unter /proc/net/tcp und /proc/net/udp. Wenn du einer der Pfade mit cat abrufst, erhälst du eine, für dich wahrscheinlich, eher obskure Ausgabe.

Netlink

Eine andere Quelle für diese Informationen wird als Netlink Protocol bezeichnet. Netlink wird verwendet, um Informationen zwischen Kernel- und User-Space-Prozessen zu übertragen. Wer Lust hat sich mit diesem sehr technischen Konzept weiter vertraut zu machen, kann sich die Informationen unter den folgenden zwei Links durchlesen.

• Netlink Library Dokumentation (libnl)
• Linux Netlink as an IP Services Protocol (RFC 3549)

Die Unterschiede – netstat vs. ss

Beide Tools unterscheiden sich zunächst einmal darin, dass sie die Information die sie dem User ausliefern, aus unterschiedlichen Quellen beziehen. Die gemeinten Quellen Procfs und Netlink hast du ja bereits kennengelernt. Direkt aus /proc/net bezieht netstat seine Daten, es analysiert die Datei und wirft die entsprechend gewünschten Informationen aus. Ss, dass neuere der beiden Tools, bezieht die gewünschten Informationen direkt über die Netlink API aus dem Kernel Space.

Die Information die mit beiden Tools abgerufen bzw. ausgegeben werden können, unterscheiden sich grundsätzlich nicht. Gerade deswegen stellt sich die Frage: Warum sollte ich eines der beiden Tools dem anderen vorziehen?

Nachfolgend liste ich einige der möglichen Gründe auf die für ss sprechen.

• Netstat gilt laut Man-Page als offiziell veraltet
• Es ist schneller
• Über Netlink können mehr TCP Zustände gequeryt werden
• Die Argumente sind generischer und die Man-Page weniger Komplex

Im großen und ganze bietet ss also kein riesiges Alleinstellungsmerkmal gegenüber Netstat und ob die aufgeführten Argumente netstat User von einem Wechsel überzeugen können, sei mal dahingestellt. Wer sich noch nicht zu sehr an Netstat gewöhnt hat oder gerade neu angekommen ist in der Linux Welt, für den ist es sicherlich ein Vorteil sich direkt an das modernere von beiden Tools zu gewöhnen. Eine weitere tolle Sache an ss ist das der Quellcode sich viel schöner lesen lässt ?

Anwendungsbeispiele ss

Im letzten Abschnitt gebe ich noch eine kleine Einführung anhand von Beispielen.
Weil ss das neue netstat ist, liegt der Fokus bei den Beispielen bewusst auf diesem Tool und nicht auf netstat. Wenn du die Man-Pages der beiden Tools vergleichst, wirst du schnell feststellen, dass die Man-Page von ss einen viel simpleren Eindruck macht und teilweise komplett andere Funktionalitäten bereitstellt. Doch der Anschein trügt, auch ss ist ein sehr mächtiges Tool wie die nachfolgenden Beispiele zeigen werden.

Im ersten Beispiel siehst du die Ausgabe von ss, ohne das ein Argument definiert wurde.
Die Ausgabe ohne ein definiertes Argument, umfasst eine Liste aller nicht lauschenden Socket Verbindungen (TCP/UNIX/UDP usw.) mit einer bestehenden Verbindung.

Bei einer so unspezifischen Anwendung kann die Ausgabe natürlich ziemlich schnell sehr lang werden. Benötigt man dennoch solch umfassende Information, bietet es sich an den stdout von ss in eine Datei umzuleiten.

ss > ss_ausgabe

Will man dagegen eine Liste aller lauschenden Socket Verbindungen erhalten, muss man die -l Option anwenden.

ss -l

Meistens wird man bei der Spurensuche jedoch genauere Vorstellungen davon haben, was gerade gesucht ist. Für eine mehr spezifische Ausgabe bietet auch ss eine einfache Handhabung, die einfach zu merken ist.

Mit den Optionen -t, -u und -x lassen sich beispielsweise TCP, UDP und UNIX Verbindungen ausgeben. Des Weiteren lassen sich mit der -f Option (steht für Family) gefolgt von der jeweiligen Socket Familie (unix, inet, inet6, link, netlink) die entsprechenden Verbindungen auflösen. Damit hast du bereits einen kleine feine Auswahl um deine Netzwerkstatistiken genauer eingrenzen zu können.

Um dir alle Verbindungen, bestehende und lauschende ausgeben zu lassen wird die -a (all) Option angehängt.

ss -u -a

Der oben stehende Befehl gibt entsprechend alle UDP Verbindungen aus.

Hast du dir deine Netzwerkstatistiken bisher mit netstat angeschaut, wird dir bei den Beispielen von ss sicherlich schon aufgefallen sein, dass bisher keine PID und auch kein Programmname mit ausgegeben wurde.

Will man mit ss eine Ausgabe wie bei dem netstat Befehl

netstat -tulpe

erzeugen, wird schon beim Vergleich der Man-Pages auffallen, dass viele Optionen gleichgehalten sind.

Der korrespondierende Befehl unter ss lautet daher auch einfach:

ss -tulpe

Wie du siehst unterscheiden sich die Ausgaben beider Tools minimal im Aufbau und im Detailgrad. Ich denke, hier ist es Geschmackssache und auch eine Frage der Gewohnheit, welche der beiden Ausgaben einem besser gefallen.

Mit der -s Option wird eine allgemeine Verbindungsstatistik erzeugt.

ss -s

TCP Zustände filtern mit ss

Nachdem wir nun schon einige Befehle kennengelernt haben zeige ich dir jetzt, was beim Filtern von TCP Zuständen mit ss alles möglich ist. Die Filterung von TCP Zuständen ist ein praktisches Features, das dir in ss zur Verfügung steht. Mit der Filterung ist es möglich TCP Verbindungen in den verschiedenen Phasen des Verbindungsaufbaus zu inspizieren.

Du kannst mittels ss alle Standard TCP Zustände abfragen:

established 
syn-sent
syn-recv
fin-wait-1
fin-wait-2
time-wait
closed
close-wait
last-ack
listen
closing

Darüber Hinaus stehen noch folgenden Optionen zur Auswahl

all - for all the states

connected - all the states except for listen and closed

synchronized - all the connected states except for syn-sent

bucket - states, which are maintained as minisockets, i.e.  time-wait and syn-recv

big - opposite to bucket

Hier ist ein Beispiel, indem TCP Verbindungen über IPv6 nach dem Zustand established gefiltert werden:

ss -t6 state established

Filterungen nach IPv4 und IPv6 werden einfach mit der Angabe von 4 oder 6 realisiert.

Im obigen Beispiel sieht man schön, wie die bestehende Verbindung zu meinem Tech4Hosting Platform Service Redis sichtbar gemacht wurde.

Auch die Syntax zum Abfragen von Zuständen ist sehr benutzerfreundlich gehalten:

Für IPv4:

ss -4 state FILTER

Für IPv6:

ss -6 state FILTER

Alle lauschenden Verbindungen für IPv4 würdest du dir beispielsweise mit folgendem Befehl ausgeben lassen:

ss -4 state listening

Filterung über IP-Adresse und Port

Eine weitere sehr nützliche Art der Filterung kann man über IP / Port und CIDR vornehmen.

Nachfolgend zeige ich dir 3 Beispiele.

Nach IP:

ss dst 70.134.160.252

Dieser Befehl gibt die Netid, den Zustand, die lokale Adresse und Port sowie die Peer Adresse und Port aus.

Ein Beispiel mit CIRD:

ss dst 70.134.160.252/16

Beispiel mit Adresse und Port Angabe:

ss dst 70.134.160.252:1335

Außerdem kann nur nach Ports gefiltert werden mit der dport/sport Option.
Eine Anfrage nach Verbindungen die auf Port 80 laufen sieht folgendermaßen aus:

ss -nt dport = :80

Auch im Zusammenspiel mit Ports bietet ss sehr viele Möglichkeiten der Filterung an.
Es werden zudem alle bekannten Vergleichsoperatoren wie >=, usw. unterstützt.
Falls ihr komplexere Abfragen formulieren müsst, wird euch die leicht verständliche Man-Page von ss sicherlich weiterhelfen.

Fazit

Wenn es ums Debuggen von Problem rund um deinen Linux-Server geht, sind die Programme ss uns netstat zwei unverzichtbare Tools. Welches der beiden du letztendlich in deinen Werkzeugkoffer steckst, bleibt dir überlassen. Wer mit dem Lauf der Zeit gehen will, sollte sich jedoch langfristig mit dem modernen Programm ss vertraut machen. Durch diesen Artikel solltest du nun bereits ein grundlegendes Verständnis davon bekommen haben, wie man mit ss umgeht. Wenn du noch tiefer in die Materie eintauchen willst, solltest du einen Blick in die Man-Page von ss werfen oder dir vielleicht sogar den Quellcode durchlesen.

Für die Zwischenzeit findest du vielleicht in diesen Tutorials:

• How to Tech4HostingTech4Hosting Kurzanleitung: S3-kompatiabler Object Storage
• Getting started mit PaaS bei Tech4Hosting
• UFW auf Ubuntu 16.04 installieren
• Debian Router/Gateway in 10 Minuten

oder wie immer in unserer Developer Community noch ein bisschen Lesestoff.

Bei Feedback, Fragen oder Anregungen kannst du uns gerne via E-Mail kontaktieren.

Zurück zur Tutorial Übersicht Back to Tutorial Overview