strongSwan blir nede etter peer-omstart: få éin tunnel tilbake

Dropp daemon-omstarten. Legg initiering og DPD på tilkoblinga som må kome tilbake, og verifiser deretter ved namn og prov tenesta, ikkje daemonen.

Fjern-gatewayen startar på nytt, kjem tilbake innan eit minutt, og den lokale strongSwan-daemonen held fram med å køyre medan tunnelen framleis er nede. Ein cron-jobb som greppar etter ESTABLISHED og startar daemonen på nytt vil til slutt dekkje over dette, og han vil også avbryte kvar urelatert tunnel på maskina medan han kanskje overser den som feila. Gjenoppretting høyrer til tilkoblinga som må kome tilbake, uttrykt i innstillingar som overlever ein reload. Denne runbooken set dette opp for éi tilkobling og provar resultatet ved namn.

Dropp den globale omstarten, ta vare på prova

Ein daemon-omstart har to konkrete manglar: han øydelegg tilstanden for kvar tilkobling, og han fortel deg ingenting om kva hending som faktisk feila. Statusteksten du greppa kan ha kome frå ei anna tilkobling, medan det naudsynte child-et sat ledig fordi ingenting utløyste det.

Les dei innlasta tilkoblingane og dei aktive assosiasjonane før du endrar noko, slik at du har eit førbilete å samanlikne med når peer-en kjem tilbake.

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

Legg initiering og gjentekne forsøk på tilkoblinga som kjem tilbake

I ein swanctl.conf-utrulling ligg desse innstillingane på tilkoblings- og child-nivå i staden for i ein global policy. Fragmentet nedanfor er eit døme frå initiatorsida som føreset at framlegg, autentisering og selektorar allereie er riktige.

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

start_action avgjer kva som skjer når child-et blir lasta: start initierer straks, medan trap installerer ein policy som utløyser initiering når passande trafikk dukkar opp. Å skrive trap|start krev strongSwan 5.9.6 eller nyare, så sjekk versjonen før du kopierer linja. dpd_action=restart ber om ny forhandling når peer-en blir erklært død, og keyingtries=0 på tilkoblingsnivå tillèt fleire forsøk fram til suksess eller ein permanent feil. Under IKEv2 har dpd_timeout ingen effekt i det heile, fordi vanleg retransmisjon avgjer når peer-en ikkje svarar.

Forsinkinga i det dømet er eit utgangspunkt og ikkje ein universell frist. Vel ho ut frå kor lang tid omstarten av peer-en tek, og kor mykje retransmisjon du er villig til å sitje gjennom.

Vit kva hending du gjenopprettar frå

Tre feil ser identiske ut på eit dashbord og krev ulike innstillingar. Ei innleiande tilkobling som aldri kom opp, er eit konfigurasjons- eller tilgjengeproblem. Ein peer som slutta å svare, er DPD-tilfellet. Eit child som peer-en lukka eksplisitt, er ei policyhending med sin eigen close_action, som DPD aldri observerer. Å lese loggen rundt avbrotet fortel deg kva av dei tre du har, og svaret endrar rettinga.

Ikkje legg aggressiv re-initiering til ei tilkobling som operatørar lukkar med vilje for vedlikehald, elles dukkar tunnelen opp midt i vindauget. For on-demand-design er ein bevart trap nok, fordi passande trafikk gjenopprettar child-et utan nokon timer.

Verifiser ved namn, ikkje ved daemon-status

Les tilkoblinga og child-et hennar ved namn medan peer-en framleis er nede, og deretter igjen når han kjem tilbake; skilnaden mellom dei to utskriftene er proved.

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

Stadfest deretter tenesta i staden for assosiasjonen. Ein fersk child-tryggleiksassosiasjon pluss ein vellukka førespurnad til den private destinasjonen bak han er det faktaparet som betyr noko, og ein køyrande daemon med ein sunn urelatert tunnel provar ingen av dei.

Viss child-et aldri initierer, sjekk at testtrafikken svarar nøyaktig til dei konfigurerte selektorane, inkludert protokoll og port. Viss det initierer og feilar, les autentiserings- eller framleggsfeilen i staden for å gøyme han bak ei endelaus løkke, fordi keyingtries=0 gjerne gientek ein permanent avvising for alltid.

Last endringa i eit vindauge, og test på nytt

Reload er tryggare enn å starte daemonen på nytt, og det er framleis ikkje gratis: å byte ut eller losse eit child kan lukke ein starta assosiasjon eller miste trap-en.

Last inn i eit vedlikehaldsvindauge, ta vare på førre fil, og stadfest at tilkoblinga viser seg med innstillingane du hadde tenkt, og ikkje med standardverdiar.

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

Rull tilbake ved å gjenopprette førre fil og laste ho inn igjen, og gjer så dei same to kommandoane om att. Ein tunnel som berre kjem tilbake etter ein daemon-omstart, er ikkje reparert, han er nullstilt.

Relaterte artiklar