Der Host im Netz: Auflösung, Listener, Paketfilter

Eine Anwendung verbindet sich auf eine veraltete IP-Adresse — das DNS-Abfragewerkzeug liefert für denselben Namen die richtige. Ein Dienst ist lokal einwandfrei erreichbar und von außen unsichtbar, ohne dass eine Firewallregel im Spiel wäre. Und eine Freigabe, die gestern funktionierte, ist nach dem Neustart weg. Alle drei sind keine Netzwerkprobleme, sondern Hostprobleme. Dieses Modul behandelt genau diese Hälfte: was ein Linux-Host selbst tut, bevor ein Paket sein Kabel verlässt — Namensauflösung, Adressvergabe, Listener und der lokale Paketfilter.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Vier Fragen, die ein Host selbst beantwortet

Netzwerkbetrieb ist ein eigenes Fach — Routing, VLANs, DNS-Serverbetrieb gehören dorthin. Dieses Modul behandelt die andere Hälfte: was der Host selbst tut, bevor überhaupt ein Paket sein Kabel verlässt.

Wie wird ein Name zu einer Adresse?: Die Auflösungskette auf diesem Host — und die ist deutlich länger als „DNS“.
Welche Adresse hat der Host, und wer hat sie gesetzt?: Statisch, per DHCP, von welchem Verwalter.
Wer hört auf welchem Port?: Der Listener und das Konto, unter dem er läuft.
Was lässt der Host durch?: Der lokale Paketfilter — und die Frage, wer seinen Zustand besitzt.

Fast jede „das Netz ist kaputt“-Meldung landet in einer dieser vier. Und in drei von vier Fällen ist das Netz vollkommen in Ordnung.

Namensauflösung ist nicht gleich DNS

Wenn ein Programm einen Namen auflösen will, fragt es nicht das Internet, sondern das System. Und das System hat eine Reihenfolge, die in /etc/nsswitch.conf steht: eine Datei, die festlegt, aus welchen Quellen Namensdienst-Informationen bezogen werden und in welcher Reihenfolge.

Für Rechnernamen ist die Zeile hosts: zuständig. Die Reihenfolge der dort genannten Quellen entscheidet: Sie werden der Reihe nach befragt, bis eine ein Ergebnis liefert.

files: Liest /etc/hosts. Steht üblicherweise vorn — ein Eintrag dort gewinnt gegen jeden DNS-Server.
dns: Die klassische DNS-Auflösung über die konfigurierten Server.
resolve: Fragt den lokalen Auflösungsdienst, sofern einer läuft.
myhostname: Liefert Antworten für den eigenen Rechnernamen, damit er auch ohne DNS auflösbar bleibt.

Die häufigste Falle im BetriebEin alter Eintrag in /etc/hosts schlägt jeden DNS-Server — und niemand denkt daran, weil alle Werkzeuge, die man zur DNS-Prüfung benutzt, diese Datei überspringen. Ein Abfragewerkzeug fragt den DNS-Server direkt und bekommt die richtige Antwort; die Anwendung geht über die Systemauflösung und bekommt die alte. Beide haben recht, und der Unterschied ist genau diese Datei.

Kurzcheck

Eine Anwendung verbindet sich auf eine veraltete IP-Adresse. Ein DNS-Abfragewerkzeug liefert für denselben Namen die korrekte neue Adresse. Wo suchst du zuerst?

In der Systemauflösung des Hosts — vor allem in /etc/hosts und der Reihenfolge in /etc/nsswitch.conf.
Beim DNS-Server — er liefert dem Werkzeug offenbar aus einem anderen Zonenstand als der Anwendung.
Im Zwischenspeicher der Anwendung — sie hat die Adresse beim Start aufgelöst und hält sie seitdem.

Treffer. Genau. Die beiden fragen unterschiedliche Dinge: Das Werkzeug fragt den DNS-Server, die Anwendung fragt das System. Ein files-Eintrag vor dns erklärt genau diese Diskrepanz.

Wer schreibt eigentlich in resolv.conf?

Die Datei /etc/resolv.conf enthält die DNS-Server, die der klassische Auflösungsweg benutzt. Sie ist auf modernen Systemen aber selten das, was sie zu sein scheint — meistens ist sie ein Verweis, und was dahinter liegt, entscheidet über das Verhalten.

Stub-Resolver — Ein lokaler Auflösungsdienst, der auf einer Adresse im Loopback-Bereich lauscht — bei systemd-resolved auf 127.0.0.53. Alle Anfragen des Hosts gehen dorthin, und er entscheidet, welchen echten DNS-Server er befragt.

Daraus folgt eine Beobachtung, die viele verwirrt: In /etc/resolv.conf steht dann als einziger Server 127.0.0.53 — also der Host selbst. Das ist kein Fehler, sondern der vorgesehene Aufbau. Welche echten Server dahinterstehen, fragt man beim Auflösungsdienst ab, nicht in der Datei.

Vier Zustände, die alle vorkommenDie Datei kann ein Verweis auf die Stub-Konfiguration sein (der empfohlene Weg), auf eine statische Fassung, auf eine ständig aktualisierte mit allen bekannten Servern — oder sie wird von einem anderen Paket verwaltet und der Auflösungsdienst liest sie nur. Bevor man dort etwas ändert, gehört geklärt, welcher der vier Zustände vorliegt. Sonst schreibt man in eine Datei, die beim nächsten Ereignis überschrieben wird.

Dasselbe Muster gilt für die Adressvergabe: Ob eine Schnittstelle statisch konfiguriert ist oder ihre Adresse per DHCP bekommt, und welcher Verwalter dafür zuständig ist, ist die erste Frage bei jeder Netzwerkänderung. Wer die Konfiguration am zuständigen Verwalter vorbei ändert, hat eine Änderung, die den nächsten Neustart nicht überlebt.

Erreichbar heißt nicht antwortend

Zwischen „der Host antwortet auf Ping“ und „der Dienst funktioniert“ liegen mehrere Stufen, und jede lässt sich einzeln belegen. Die Reihenfolge spart die meiste Zeit, wenn man sie einhält.

Name löst auf: Die Systemauflösung liefert eine Adresse — und zwar die erwartete.
Adresse erreichbar: Pakete kommen an. Sagt nichts über einen Dienst.
Port offen: Etwas nimmt auf diesem Port Verbindungen an.
Dienst antwortet fachlich: Die Anwendung liefert eine sinnvolle Antwort, nicht nur einen offenen Port.

Auf dem Host selbst beantwortet ss die dritte Frage: Welche Sockets sind offen, auf welcher Adresse und welchem Port, und welcher Prozess gehört dazu. Das ist der Unterschied zwischen „irgendwas hört da“ und „der richtige Dienst hört da“.

Die Bindeadresse ist eine eigene FehlerquelleEin Dienst, der nur an 127.0.0.1 gebunden ist, ist lokal perfekt erreichbar und von außen unsichtbar — ohne dass eine einzige Firewallregel im Spiel wäre. Das Fehlerbild sieht aus wie ein blockierter Port und ist keiner. Vor jeder Firewall-Analyse gehört deshalb der Blick darauf, woran der Dienst überhaupt gebunden ist.

Der lokale Paketfilter und die Frage nach dem Besitzer

Jeder Linux-Host filtert Pakete im Kernel. Verwaltet wird dieser Regelsatz aber praktisch nie von Hand, sondern von einem Dienst darüber — auf vielen Server-Distributionen etwa von einer zonenbasierten Verwaltung, die aus ihrer eigenen Konfiguration den Regelsatz erzeugt.

Daraus folgt die wichtigste Regel dieses Abschnitts: Es darf nur einen Besitzer des Regelzustands geben. Wer zusätzlich zur Verwaltung eigene Regeln direkt in den Kernel schreibt, erzeugt eine zweite Ebene, die niemand mehr gemeinsam liest — und die beim nächsten Neuladen der Verwaltung verschwindet oder mit ihr kollidiert.

Ein Port soll für ein Nachbarsystem geöffnet werden

Szenario

Ein Dienst auf Port 8443 soll von genau einem anderen Server erreichbar sein. Der Host wird von einer zonenbasierten Firewallverwaltung betreut.

Anforderungen

Die Öffnung ist auf Quelle und Dienst begrenzt, nicht global
Die Regel überlebt einen Neustart
Der wirksame Zustand ist danach belegbar

Schritte

Zuerst prüfen, ob der Dienst überhaupt auf einer von außen erreichbaren Adresse gebunden ist — sonst behebt keine Firewallregel etwas.
Die Änderung im vorgesehenen Modell vornehmen, nicht daneben: also in der Verwaltung, die den Regelsatz erzeugt.
Die Freigabe eng fassen — Quelladresse und Zielport, nicht der Port für alle.
Laufzeit und Persistenz getrennt prüfen: Eine Regel kann jetzt wirken und nach dem Neustart weg sein, oder umgekehrt hinterlegt und noch nicht aktiv sein.
Vom Nachbarsystem aus gegenprüfen — und von einem dritten, das es nicht dürfen soll.

Merksatz: Der letzte Schritt ist der, den fast alle auslassen. Eine Freigabe ist erst dann geprüft, wenn auch belegt ist, dass sie nicht mehr öffnet als beabsichtigt.

Zwei Zustände, die auseinanderlaufen können

Bei fast jeder Netzwerkkonfiguration auf einem Host gibt es einen laufenden und einen hinterlegten Zustand. Sie können sich unterscheiden, und beide Richtungen kommen vor.

Wirkt jetzt, ist nicht hinterlegt: Die klassische Notfalländerung. Funktioniert bis zum nächsten Neustart und verschwindet dann — samt der Erklärung, warum vorher alles ging.
Hinterlegt, wirkt noch nicht: Die Änderung ist geschrieben, aber niemand hat sie neu einlesen lassen. Sie greift beim nächsten Neustart — überraschend für den, der dann Dienst hat.

Warum das gerade beim Netzwerk gefährlich istWer eine Netzwerkänderung nur laufend setzt und sich per SSH verbunden hat, verliert bei einem Fehler die Verbindung — und ein Neustart stellt den funktionierenden Zustand wieder her. Das ist die einzige Situation, in der die fehlende Persistenz ein Vorteil ist: Genau deshalb ändert man Netzwerkkonfiguration aus der Ferne gern erst laufend, prüft, und schreibt erst danach fest.

Wo dieses Modul aufhört

Alles bisher Genannte passiert auf dem Host. Sobald ein Paket ihn verlässt, beginnt ein anderes Fach: Routing zwischen Netzen, VLAN-Grenzen, der Betrieb von DNS-Servern und deren Zonen, DHCP-Bereiche, Lastverteilung.

Die Trennung ist im Alltag nützlich, weil sie die Zuständigkeit klärt. Ein Dienst, der lokal antwortet und von außen nicht erreichbar ist, ist zuerst ein Host-Problem — Bindeadresse, lokaler Filter, Auflösung. Erst wenn die vier Fragen vom Anfang alle mit Ja beantwortet sind, lohnt der Weg zum Netzwerkteam.

Der praktische Nutzen dieser GrenzeSie verhindert die teuerste Sorte Fehlersuche: zwei Teams, die gleichzeitig an verschiedenen Enden suchen, weil niemand belegt hat, auf welcher Seite der Grenze das Problem liegt. Vier Belege vom Host aus sind billiger als eine Stunde Abstimmung.

Wenn der Host selbst der Client ist

Bisher ging es um eingehende Verbindungen. Die andere Richtung ist im Betrieb genauso häufig und wird deutlich seltener sauber geprüft: Der Host selbst muss etwas erreichen — ein Paketrepository, einen Zeitserver, eine API.

Die Kette ist dieselbe, nur umgekehrt gelesen: Erst muss der Name auflösen, dann muss eine Route nach draußen existieren, dann muss ein möglicherweise vorhandener ausgehender Filter das erlauben — und bei manchen Umgebungen sitzt zusätzlich ein Vermittler dazwischen, den die Anwendung kennen muss.

Die unsichtbare Hälfte der Proxy-KonfigurationEin Vermittler wird auf Linux üblicherweise über Umgebungsvariablen bekanntgegeben — und die gelten nur für Prozesse, die sie geerbt haben. Ein Kommando in deiner Sitzung erreicht damit das Ziel, während derselbe Dienst unter systemd es nicht erreicht: Er hat deine Sitzung nie gesehen. Wer den Proxy nur in der eigenen Shell setzt, testet etwas anderes als das, was im Betrieb läuft.

Praktisch heißt das: Ein ausgehender Test gehört unter demselben Konto und in derselben Umgebung ausgeführt wie der Dienst, um den es geht. Alles andere beweist nur, dass dein Weg nach draußen funktioniert.

Zwei Adressfamilien nebeneinander

Fast jeder Host spricht heute IPv4 und IPv6 gleichzeitig. Im Normalfall merkt man davon nichts — und genau deshalb ist der Ausnahmefall so verwirrend.

Löst ein Name auf beide Adressfamilien auf, muss der Client sich für eine entscheiden, und moderne Systeme bevorzugen dabei üblicherweise IPv6. Ist das Ziel dort nicht erreichbar — kein Listener, keine Route, keine Regel —, entsteht ein Fehlerbild, das nach Zufall aussieht: Manche Werkzeuge funktionieren, andere nicht, und ein Wechsel des Namens auf die reine Adresse behebt es plötzlich.

Dienst nur auf IPv4 gebunden: Der Name löst auch auf IPv6 auf, dort hört aber niemand. Der Client versucht es zuerst dort.
Filterregel nur für IPv4: Die Freigabe existiert — für die andere Adressfamilie aber nicht. Zwei Regelsätze, einer gepflegt.
Nur ein Eintrag im Namensdienst: Kein Problem: Es gibt nichts zu wählen. Deshalb fällt der Fehler erst auf, wenn jemand den zweiten Eintrag ergänzt.

Der schnelle TestWenn eine Verbindung über den Namen scheitert und über die ausgeschriebene IPv4-Adresse funktioniert, ist die Adressfamilie die erste Hypothese — nicht der Namensdienst. Beide Familien gehören danach gleich behandelt: gleicher Listener, gleiche Regel, oder bewusst nur eine, aber dann auch nur ein Eintrag im Namensdienst.

Was der Host über bestehende Verbindungen verrät

Offene Ports sind die eine Hälfte der Bestandsaufnahme. Die andere sind die bestehenden Verbindungen: wer redet gerade mit wem, in welchem Zustand, und wie viele davon gibt es.

Dasselbe Werkzeug, das Listener anzeigt, zeigt auch sie. Zwei Beobachtungen daraus tragen im Betrieb überraschend weit.

Viele Verbindungen im Wartezustand: Ein Gegenüber antwortet nicht mehr oder langsam. Häufig ein Hinweis auf ein Problem auf der anderen Seite, nicht auf diesem Host.
Ausgehende Verbindungen zu unerwarteten Zielen: Ein Dienst spricht mit etwas, das im Betriebsmodell nicht vorgesehen war. Der erste Griff bei einer Auffälligkeit — und der billigste.
Verbindungen, die sich häufen statt abzubauen: Ein Hinweis auf Verbindungen, die niemand schließt. Läuft irgendwann in eine Ressourcengrenze des Prozesses.

Warum das kein Netzwerkthema istDiese Beobachtungen macht man auf dem Host, ohne Zugriff auf Switches oder Firewalls. Sie beantworten die Frage, ob der Host tut, was er soll — und in vielen Fällen erledigt sich damit die Anfrage an das Netzwerkteam, bevor sie gestellt wird.

Und sie schließen den Bogen zu den vier Fragen vom Anfang: Wer auflöst, wer bindet, wer filtert und wer redet, ist zusammen das vollständige Bild eines Hosts in seinem Netz. Jede dieser Fragen ist auf dem Host selbst beantwortbar, und drei von vier ohne jede Änderung.

Der Host-Name und wo er überall steht

Ein scheinbar triviales Thema, das regelmäßig Zeit kostet: Wie ein Host heißt, steht an mehreren Stellen — und sie können auseinanderlaufen.

Der gesetzte Rechnername: Was das System über sich selbst sagt. Wird beim Start gesetzt und lässt sich zur Laufzeit ändern.
Der Eintrag in `/etc/hosts`: Sorgt dafür, dass der eigene Name auch ohne DNS auflöst. Fehlt er, warten manche Programme beim Start in ein Zeitlimit.
Der Eintrag im Namensdienst: Was andere sehen. Muss mit dem Rechnernamen nicht übereinstimmen — und tut es nach Umzügen oft nicht.
Was der Verwalter setzt: Bei Adressvergabe per DHCP kann der Name von dort kommen und eine lokale Einstellung überschreiben.

Das typische FehlerbildEin Dienst, der seinen eigenen Namen auflösen will und dabei in ein Zeitlimit läuft, verzögert den Start um eine auffällig runde Zeitspanne. Die Ursache ist fast immer ein fehlender oder falscher Eintrag für den eigenen Namen in der lokalen Datei — nicht der DNS-Server, den alle zuerst verdächtigen.

Für Zertifikate ist dieselbe Frage noch schärfer: Ein Zertifikat gilt für einen Namen, nicht für einen Host. Stimmt der Name, unter dem ein Client den Dienst anspricht, nicht mit dem im Zertifikat überein, scheitert die Verbindung — obwohl Netzwerk, Auflösung und Dienst alle einwandfrei arbeiten.

Die Reihenfolge bei einem Verbindungsproblem

Namensauflösung über die Systemauflösung prüfen, nicht nur den DNS-Server→Erreichbarkeit der Adresse belegen→Auf dem Zielhost nachsehen, ob und woran der Dienst gebunden ist→Erst danach den lokalen Paketfilter ansehen — im vorgesehenen Modell→Laufzeit und Persistenz jeder Änderung getrennt verifizieren

Die Reihenfolge ist bewusst so gewählt, dass jeder Schritt den nächsten überflüssig machen kann. Löst der Name falsch auf, braucht niemand die Firewall anzusehen. Ist der Dienst nur an die Loopback-Adresse gebunden, erklärt das alles Weitere. Wer stattdessen mit der Firewall anfängt — dem sichtbarsten und am häufigsten verdächtigten Bestandteil —, prüft zuerst das, was am seltensten die Ursache ist, und ändert dabei oft etwas, das vorher richtig war.

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Namensauflösung ist nicht DNS — die Reihenfolge in nsswitch.conf entscheidet, und /etc/hosts gewinnt. `resolv.conf` ist meist ein Verweis — kläre, wer sie schreibt, bevor du sie änderst. Erreichbar ist nicht antwortend, und eine Bindeadresse auf Loopback sieht aus wie eine Firewallregel. Und der Regelzustand hat genau einen Besitzer — eine zweite Ebene daneben macht den wirksamen Zustand unlesbar.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität7 Primärquellen · zuletzt geprüft: 2026-09-03