strongSwan blijft plat na een peer-reboot: één tunnel herstellen

De externe gateway start opnieuw op, komt binnen een minuut terug, en de lokale strongSwan-daemon blijft draaien terwijl de tunnel nog plat ligt. Een cronjob die op ESTABLISHED grept en de daemon herstart, verdoezelt dat uiteindelijk, en onderbreekt ook elke ongerelateerde tunnel op de machine terwijl hij misschien net degene mist die faalde. Herstel hoort bij de verbinding die terug moet komen, uitgedrukt in instellingen die een reload overleven. Deze runbook zet dat op voor één verbinding en bewijst het resultaat op naam.

Laat de globale restart varen, bewaar het bewijs

Een daemon-restart heeft twee concrete gebreken: hij vernietigt de toestand van elke verbinding, en hij vertelt je niets over welke gebeurtenis werkelijk faalde. De statustekst die je grepte, kan van een andere verbinding komen, terwijl het benodigde child niets deed omdat niets het activeerde.

Lees de geladen verbindingen en de actieve associaties voordat je iets wijzigt, zodat je een vooraf-beeld hebt om mee te vergelijken als de peer terugkomt.

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

Zet initiatie en herhaalpogingen op de verbinding die terugkomt

In een swanctl.conf-implementatie staan deze instellingen op verbindings- en child-niveau in plaats van in een globaal beleid. Het fragment hieronder is een voorbeeld aan de initiatorzijde dat aanneemt dat voorstellen, authenticatie en selectors al kloppen.

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

start_action bepaalt wat er gebeurt als het child wordt geladen: start initieert onmiddellijk, terwijl trap een beleid installeert dat initiatie afvuurt zodra passend verkeer verschijnt. trap|start schrijven vereist strongSwan 5.9.6 of nieuwer, dus controleer de versie voordat je de regel kopieert. dpd_action=restart vraagt om nieuwe onderhandeling zodra de peer dood wordt verklaard, en keyingtries=0 op verbindingsniveau staat verdere pogingen toe tot succes of een permanente fout. Onder IKEv2 heeft dpd_timeout helemaal geen effect, omdat gewone hertransmissie bepaalt wanneer de peer niet reageert.

De vertraging in dat voorbeeld is een uitgangspunt en geen universele deadline. Kies hem op basis van hoe lang de reboot van de peer duurt en hoeveel hertransmissie je bereid bent te doorstaan.

Weet van welke gebeurtenis je herstelt

Drie storingen zien er identiek uit op een dashboard en vragen andere instellingen. Een initiële verbinding die nooit omhoogkwam, is een configuratie- of bereikbaarheidsprobleem. Een peer die stopte met antwoorden, is het DPD-geval. Een child die de peer expliciet sloot, is een beleidsgebeurtenis met zijn eigen close_action, die DPD nooit waarneemt. De log rond de storing lezen vertelt je welke van de drie je hebt, en het antwoord verandert de oplossing.

Voeg geen agressieve her-initiatie toe aan een verbinding die operators bewust sluiten voor onderhoud, anders verschijnt de tunnel midden in het venster weer. Voor on-demand-ontwerpen is een bewaarde trap genoeg, omdat passend verkeer het child zonder enige timer opnieuw opbouwt.

Verifieer op naam, niet op daemonstatus

Lees de verbinding en haar child op naam terwijl de peer nog plat ligt, en daarna opnieuw als hij terugkomt; het verschil tussen die twee uitvoer is het bewijs.

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

Bevestig daarna de dienst in plaats van de associatie. Een verse child-beveiligingsassociatie plus een geslaagd verzoek aan de privébestemming erachter zijn het paar feiten dat telt, en een draaiende daemon met een gezonde ongerelateerde tunnel bewijst geen van beide.

Als het child nooit initieert, controleer dan of het testverkeer precies overeenkomt met de geconfigureerde selectors, inclusief protocol en poort. Als het initieert en faalt, lees dan de authenticatie- of voorstelfout in plaats van die achter een eindeloze lus te verbergen, want keyingtries=0 herhaalt een permanente afwijzing graag voor altijd.

Laad de wijziging in een venster en test opnieuw

Reload is veiliger dan de daemon herstarten, en het is nog steeds niet gratis: een child vervangen of lossen kan een gestarte associatie sluiten of zijn trap laten vallen.

Laad tijdens een onderhoudsvenster, bewaar het vorige bestand, en bevestig dat de verbinding verschijnt met de instellingen die je bedoelde en niet met standaardwaarden.

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

Draai terug door het vorige bestand te herstellen en opnieuw te laden, en herhaal dan dezelfde twee opdrachten. Een tunnel die pas na een daemon-restart terugkomt, is niet gerepareerd, hij is gereset.