Ausgehendes ESP ohne Antwort heißt nicht, dass das VPN tot ist
ESP schützt eine Richtung pro Assoziation und bestätigt nichts. Gleichen Sie die innere Unterhaltung und die eingehende SA ab, bevor Sie den Server als antwortlos bezeichnen.
Sie haben den Verkehr auf dem IPsec-Host mitgeschnitten, ESP-Pakete abgehen sehen, nichts zurückkommen sehen und daraus geschlossen, dass die Gegenseite defekt ist. Der Mitschnitt stützt diesen Schluss nicht. ESP schützt eine Richtung einer Unterhaltung und bestätigt auf der IP-Ebene nichts, sodass fehlendes Rück-ESP ebenso gut bedeuten kann, dass die Anwendung nichts zu sagen hatte, wie dass der Tunnel tot ist. Lesen Sie den inneren Austausch und den Zustand der Empfangsseite, bevor Sie eine der beiden Seiten beschuldigen.
Der Mythos: jedes geschützte Paket verdient eine Antwort
ESP ist kein Anforderung-Antwort-Protokoll. Es verschlüsselt und authentifiziert, was die Richtlinie auswählt, und der Empfänger prüft, entschlüsselt und liefert dieses innere Paket, ohne ein eigenes Paket zu erzeugen. Eine UDP-Abfrage, die das Ziel ignoriert, oder ein ICMP-Echo, das die eingehende Richtlinie verwirft, erzeugen in beide Richtungen Stille als das korrekte Ergebnis. Diese Stille als Transportfehler zu behandeln, schickt Sie auf die Suche nach einem Netzwerkfehler, den es nie gab.
Was ein einseitiger Mitschnitt tatsächlich belegt, ist, dass der Stack des Absenders an diesem Beobachtungspunkt etwas verschlüsselt hat. Nichts über die Ankunft und nichts über die Absicht zu antworten. Die nützliche Frage ist nicht "warum gibt es keine Antwort", sondern "was hätte die innere Unterhaltung erzeugen müssen".
Zwei SAs, zwei SPIs, eine Unterhaltung
IPsec-Sicherheitsassoziationen sind unidirektional, daher umfasst ein normaler geschützter Austausch eine eingehende und eine ausgehende Assoziation mit getrennten Bezeichnern und unabhängigem Zustand. Den Rückverkehr nach der SPI des ausgehenden Pakets zu suchen, ist deshalb ein Kategorienfehler, weil jede Antwort unter der eigenen ausgehenden SA des Peers mit dessen eigener SPI läuft. Gleichen Sie das Paar stattdessen über Traffic-Selektoren und Peer-Adressen ab.
Eine Schlüsselerneuerung verkompliziert das Bild für ein paar Sekunden, da alter und neuer Zustand überlappen können. Begann das Symptom um eine Schlüsselerneuerung herum, sammeln Sie Assoziationsbezeichner und Zeitstempel gemeinsam, statt nur den Verbindungsnamen.
Was der Empfänger tun muss, bevor irgendetwas antwortet
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Jede Zeile scheitert unabhängig, und jedes Scheitern hat einen anderen Verantwortlichen, weshalb ein einzelner Mitschnitt sie nicht unterscheiden kann. Der eingehende Zähler ist der einzige direkte Beleg für die Ankunft, weil ein Paket, das seine Authentifizierung oder Replay-Prüfung nicht besteht, ohne jede Antwort verworfen wird. Ein Peer, dessen eingehender Zähler sich nicht bewegt hat, teilt Ihnen daher überhaupt nichts über seine Richtlinie mit.
Die Zustellung ist ein eigener Schritt gegenüber der Entschlüsselung. Der Zustand kann gültig sein und das Paket dennoch anschließend von einer eingehenden Richtlinie oder einer Route verworfen werden, die das innere Ziel nicht enthält, prüfen Sie also, ob der Zielhost Klartext gesehen hat, statt anzunehmen, ein sauberer Zähler bedeute, das Paket sei dort angekommen, wo Sie es haben wollten.
Echtes ESP ist kein UDP
Echtes ESP ist IP-Protokoll 50, das weder TCP noch UDP ist und überhaupt keine Ports hat. Eine Firewall-Regel, die IKE auf UDP 500 erlaubt, sagt daher nichts über den Datenpfad aus, und ein um Ports herum geschriebener Filter kann einen Tunnel aushandeln lassen und dann alles verwerfen, was in ihm befördert wird. Testen Sie den Datenpfad für sich, in dem Modus, den Sie tatsächlich beobachtet haben.
Hinter einem NAT ändert sich die Form: Die geschützte Nutzlast reist innerhalb von UDP, üblicherweise auf Port 4500, wie RFC 3948 festlegt. Halten Sie den aktiven Modus fest, bevor Sie eine Regel schreiben, denn ein Gerät auf dem Pfad kann echtes ESP und UDP-gekapseltes ESP völlig unterschiedlich behandeln, und manche Middleboxes erlauben das eine und verwerfen das andere.
Zähler lesen, die zu diesem Vorfall gehören
Auf einem strongSwan-Host meldet swanctl --list-sas Paket- und Byte-Zähler pro Assoziation in beide Richtungen, was ausreicht, um "nie angekommen" von "angekommen und nicht beantwortet" zu trennen. Unter Linux zählt /proc/net/xfrm_stat aggregierte Fehler wie fehlenden Zustand, fehlende Richtlinie und Protokollfehler. Diese Summen sammeln sich seit dem Start an und gehören zu einem Netzwerk-Namespace, sodass eine große Zahl noch keine Zuordnung ist.
Nehmen Sie zwei Messungen um das Vorfallfenster im richtigen Namespace und vergleichen Sie die Differenzen, sonst hängen Sie die Fehler der letzten Woche an das Ticket von heute Nachmittag. Schreiben Sie den Namespace und beide Zeitstempel ins Ticket, damit der nächste Leser den Vergleich reproduzieren kann, statt einer Summe zu vertrauen.
Benennen Sie die Stufe, nicht den Verdächtigen
Eine brauchbare Schlussfolgerung sagt, wo das Paket stehen blieb: nie empfangen, empfangen und verworfen, zugestellt aber unbeantwortet oder beantwortet und auf dem Rückweg verloren. Jeder dieser Punkte verweist auf einen anderen Verantwortlichen und einen anderen nächsten Befehl. "Keine Antwort vom VPN-Server" presst vier verschiedene Fehler in einen Satz, den der Mitschnitt nie gerechtfertigt hat.
Halten Sie Mitschnitte eng und rohen Kernelzustand aus Tickets heraus, da er Schlüsselmaterial tragen kann, das den Host nicht verlassen sollte. Die Zählerdifferenzen und die Zeitstempel sind die Teile, die es wert sind, an die nächste Person weitergegeben zu werden.