strongSwan bleibt nach einem Peer-Neustart unten: einen Tunnel zurückholen

Verabschieden Sie sich vom Daemon-Neustart. Legen Sie Initiierung und DPD auf die Verbindung, die zurückkommen muss, und prüfen Sie dann über den Namen und belegen Sie den Dienst, nicht den Daemon.

Das entfernte Gateway startet neu, ist binnen einer Minute wieder da, und der lokale strongSwan-Daemon läuft weiter, während der Tunnel unten bleibt. Ein Cron-Job, der nach ESTABLISHED grept und den Daemon neu startet, überdeckt das irgendwann – und unterbricht dabei jeden unbeteiligten Tunnel auf der Maschine, während er womöglich genau den verfehlt, der ausgefallen ist. Die Wiederherstellung gehört zu der Verbindung, die zurückkommen muss, ausgedrückt in Einstellungen, die ein Reload überstehen. Dieses Runbook richtet das für eine einzelne Verbindung ein und belegt das Ergebnis über den Namen.

Den globalen Neustart verabschieden, seine Beweise behalten

Ein Daemon-Neustart bringt zwei konkrete Mängel mit: Er zerstört den Zustand jeder Verbindung, und er sagt Ihnen nichts darüber, welches Ereignis tatsächlich fehlgeschlagen ist. Der Statustext, den Sie gegrept haben, kann von einer anderen Verbindung stammen, während das benötigte Child untätig blieb, weil nichts es ausgelöst hat.

Lesen Sie die geladenen Verbindungen und die aktiven Assoziationen, bevor Sie etwas ändern, damit Sie ein Vorher-Bild besitzen, mit dem Sie nach der Rückkehr des Peers vergleichen können.

swanctl --list-conns
swanctl --list-sas

Initiierung und Wiederholungen auf die zurückkehrende Verbindung legen

In einer swanctl.conf-Bereitstellung liegen diese Einstellungen auf Verbindungs- und Child-Ebene und nicht in einer globalen Policy. Das folgende Fragment ist ein Beispiel für die Initiator-Seite, das davon ausgeht, dass Vorschläge, Authentifizierung und Selektoren bereits korrekt sind.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action entscheidet, was beim Laden des Childs passiert: start initiiert sofort, während trap eine Policy installiert, die die Initiierung auslöst, wenn passender Traffic auftritt. trap|start zu schreiben erfordert strongSwan 5.9.6 oder neuer, prüfen Sie also die Version, bevor Sie die Zeile übernehmen. dpd_action=restart fordert eine neue Aushandlung an, sobald der Peer für tot erklärt wird, und keyingtries=0 auf Verbindungsebene erlaubt weitere Versuche bis zum Erfolg oder einem dauerhaften Fehler. Unter IKEv2 hat dpd_timeout überhaupt keine Wirkung, weil die gewöhnliche Neuübertragung entscheidet, wann der Peer nicht antwortet.

Die Verzögerung in diesem Beispiel ist ein Ausgangspunkt und keine allgemeingültige Frist. Wählen Sie sie danach, wie lange der Neustart des Peers dauert und wie viele Neuübertragungen Sie durchstehen wollen.

Wissen, von welchem Ereignis Sie sich erholen

Drei Fehler sehen auf einem Dashboard gleich aus und brauchen unterschiedliche Einstellungen. Eine anfängliche Verbindung, die nie zustande kam, ist ein Konfigurations- oder Erreichbarkeitsproblem. Ein Peer, der nicht mehr antwortet, ist der DPD-Fall. Ein Child, das der Peer ausdrücklich geschlossen hat, ist ein Policy-Ereignis mit eigenem close_action, das DPD nie beobachtet. Das Lesen des Logs rund um den Ausfall sagt Ihnen, welchen der drei Sie haben, und die Antwort ändert die Lösung.

Fügen Sie einer Verbindung keine aggressive Neu-Initiierung hinzu, die Betreiber absichtlich für Wartungsarbeiten schließen, sonst erscheint der Tunnel mitten im Wartungsfenster wieder. Für On-Demand-Designs reicht ein beibehaltener trap, weil passender Traffic das Child ohne jeden Timer neu aufbaut.

Über den Namen prüfen, nicht über den Daemon-Status

Lesen Sie die Verbindung und ihr Child über den Namen, während der Peer noch unten ist, und dann erneut, sobald er zurück ist; die Differenz zwischen diesen beiden Ausgaben ist der Beweis.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Bestätigen Sie dann den Dienst und nicht die Assoziation. Eine frische Child-Security-Assoziation plus eine erfolgreiche Anfrage an das private Ziel dahinter sind das entscheidende Faktenpaar, und ein laufender Daemon mit einem gesunden unbeteiligten Tunnel beweist keines von beiden.

Wenn das Child nie initiiert, prüfen Sie, ob der Test-Traffic exakt zu den konfigurierten Selektoren passt, einschließlich Protokoll und Port. Wenn es initiiert und scheitert, lesen Sie den Authentifizierungs- oder Vorschlagsfehler, statt ihn hinter einer endlosen Schleife zu verstecken, denn keyingtries=0 wiederholt eine dauerhafte Ablehnung fröhlich für immer.

Die Änderung in einem Wartungsfenster laden und erneut testen

Ein Reload ist sicherer als ein Neustart des Daemons, und er ist trotzdem nicht kostenlos: Das Ersetzen oder Entladen eines Childs kann eine gestartete Assoziation schließen oder seinen trap fallen lassen.

Laden Sie während eines Wartungsfensters, behalten Sie die vorherige Datei, und bestätigen Sie, dass die Verbindung mit den beabsichtigten Einstellungen und nicht mit Vorgaben erscheint.

swanctl --load-conns
swanctl --list-conns

Rollen Sie zurück, indem Sie die vorherige Datei wiederherstellen und erneut laden, und wiederholen Sie dann dieselben zwei Befehle. Ein Tunnel, der erst nach einem Daemon-Neustart zurückkommt, ist nicht repariert, sondern zurückgesetzt.

Ähnliche Artikel