Eine Linux-VPN-Schnittstelle mit ip link Schicht für Schicht prüfen

Das Symbol des Clients meldet verbunden, die Schnittstelle existiert, und die Anwendung erreicht trotzdem nichts. Diese Kombination ist häufig, denn eine virtuelle Schnittstelle kann bestehen bleiben, während ihre Gegenseite, ihre Adressen oder ihre Routen fehlen. ip link ist das richtige erste Werkzeug und zugleich das leichteste, das man überinterpretiert. Flags und Zähler beschreiben eine Schicht, und die Schichten darüber scheitern unabhängig davon. Es ist außerdem das Werkzeug, das Leute zitieren, wenn sie beweisen wollen, dass der Tunnel steht – genau die Aussage, die es allein nicht tragen kann.

Lies die Schnittstelle, bevor du das Symbol liest

Beginne mit ip -details link show dev tun0 wie im Handbuch zu ip-link, und setze dabei die Schnittstelle ein, die dein Client tatsächlich besitzt, statt des üblichen Namens. Flags, Typ, MTU und Identität der Schnittstelle sind nützliche Beobachtungen. Die Zustandsbeschreibung einer virtuellen Schnittstelle muss sich nicht wie die Trägeranzeige eines physischen Kabels verhalten, also behandle UP als Aussage über die Schnittstelle und nicht über den Tunnel.

Diese Unterscheidung erklärt den verwirrendsten Fall: eine Schnittstelle, die bestehen bleibt, während die Gegenseite neu verbindet oder nicht erreichbar ist.

Persistenz-Einstellungen können den Link genau deshalb bestehen lassen, damit das erneute Verbinden ihn nicht neu aufbaut – das heißt, Anwesenheit ist nicht Gesundheit.

Zähler ergänzen und eine Anfrage stellen, die sie nutzen sollte

Nutze die unterstützte Statistikansicht ip -s link show dev tun0, und notiere die Paket- und Byte-Zähler in beide Richtungen. Erzeuge dann eine harmlose Anfrage, die die Schnittstelle durchlaufen sollte, und vergleiche die relevante Richtung. Eine Anfrage, die über den direkten Weg einer anderen Anwendung lief, bewegt diese Zähler nicht, und genau darum geht es bei der Übung.

Wenn der Sendezähler steigt und der Empfangszähler nicht, ist das Paket hinausgegangen und nichts zurückgekommen. Das ist ein anderes Problem als eine Schnittstelle, die nie etwas übertragen hat. Wenn beide Zähler steigen und die Anwendung trotzdem scheitert, sitzt der Fehler oberhalb der Schnittstelle – das ist Fortschritt und keine Sackgasse.

Nimm den Messwert zweimal, einmal davor und einmal danach, statt einem einzelnen Schnappschuss zu vertrauen.

Adressen und Routen sind getrennte Schritte

Ein Link kann ohne das Präfix, die Resolver-Konfiguration oder die Route existieren, die die Anwendung braucht. Prüfe die Adresse mit ip address show dev tun0, dann prüfe, welche Route das Ziel mit ip route get für das tatsächliche Ziel wählen würde. Diese drei Beobachtungen beantworten drei verschiedene Fragen, und nur die letzte betrifft die Weiterleitung.

Bei IPsec können zudem Sicherheitsrichtlinie und Association-Status zählen, und nicht jedes IPsec-Design erscheint als einfache tun-Schnittstelle. Nach einem tun-Gerät zu suchen, das nie existieren sollte, ist ein schneller Weg zur falschen Schlussfolgerung.

Notiere den genauen Namen, den Namespace und den Zeitpunkt bei jeder Ausgabe, die du aufbewahrst, denn ein gleich aussehender Name in einem anderen Container oder einer wiederhergestellten Sitzung steht für einen völlig anderen Kontext.

Lösche nicht, was du nicht identifiziert hast

Eine unbekannte Schnittstelle ist nicht automatisch veraltet. Kläre ihren Besitzer, bevor du etwas entfernst, und nutze den dokumentierten Abbau des Clients oder die verwaltete Konfiguration, wenn das Entfernen wirklich beabsichtigt ist. Einen laufenden Tunnel zu löschen, um zu sehen, was passiert, ist ein Test, der eine Frage beantwortet, die niemand gestellt hat.

Wenn die Schnittstelle zu einer Container-Laufzeit oder einem Netzwerk-Namespace gehört, den du nicht erstellt hast, ist der Besitzer einen Befehl entfernt und es lohnt sich, ihn zuerst zu finden.

Diese Vorsicht gilt auch für ip link set down, was umkehrbar aussieht und es oft nicht ist.

Was die Prüfung dir hinterlassen sollte

Eine gute Prüfung endet mit vier Fakten: dem Namen und Namespace der Schnittstelle, ihren Flags und der MTU, dem Zählerdelta aus einer echten Anfrage sowie der Route und Adresse, die die Anwendung tatsächlich braucht. Wenn diese notiert sind, ist der nächste Schritt offensichtlich und gehört zu einer bestimmten Schicht. Ohne sie ist jede weitere Änderung eine Vermutung mit Rückrollplan.

Vergleiche diese vier Fakten mit denselben vier aus einer funktionierenden Sitzung. Wenn Name und Namespace übereinstimmen, das Zählerdelta aber null ist, hat die Anfrage den Tunnel nie erreicht. Wenn das Zählerdelta gesund ist und die Route woanders hinzeigt, ist der Tunnel in Ordnung und die Weiterleitung nicht. Dieser Vergleich macht aus einem Haufen Ausgabe eine Entscheidung.

Bewahre die Ausgabe beim Ticket auf, denn ein späterer Vergleich nützt nur, wenn du siehst, was sich geändert hat.

Dann schließt du den Kreis, indem du die Anwendung erneut testest, denn die Schnittstelle war nie das, was den Nutzer interessierte.