strongSwan blir nede etter peer-omstart: gjenopprett én tunnel

Dropp daemon-omstarten. Legg initiering og DPD på tilkoblingen som må komme tilbake, og verifiser deretter ved navn og bevis tjenesten, ikke daemonen.

Fjern-gatewayen starter på nytt, kommer tilbake innen et minutt, og den lokale strongSwan-daemonen fortsetter å kjøre mens tunnelen fortsatt er nede. En cron-jobb som grepper etter ESTABLISHED og restarter daemonen vil til slutt dekke over dette, og den vil også avbryte hver urelatert tunnel på maskinen mens den kanskje overser den som feilet. Gjenoppretting hører til tilkoblingen som må komme tilbake, uttrykt i innstillinger som overlever en reload. Denne runbooken setter opp dette for én tilkobling og beviser resultatet ved navn.

Dropp den globale omstarten, behold bevisene

En daemon-omstart har to konkrete mangler: den ødelegger tilstanden for hver tilkobling, og den forteller deg ingenting om hvilken hendelse som faktisk feilet. Statusteksten du grep, kan ha kommet fra en annen tilkobling, mens det nødvendige child-et satt ledig fordi ingenting utløste det.

Les de innlastede tilkoblingene og de aktive assosiasjonene før du endrer noe, slik at du har et førbilde å sammenligne med når peer-en kommer tilbake.

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

Legg initiering og gjentatte forsøk på tilkoblingen som kommer tilbake

I en swanctl.conf-utrulling ligger disse innstillingene på tilkoblings- og child-nivå i stedet for i en global policy. Fragmentet nedenfor er et eksempel fra initiatorsiden som forutsetter at forslag, autentisering og selektorer allerede er riktige.

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

start_action avgjør hva som skjer når child-et lastes: start initierer umiddelbart, mens trap installerer en policy som utløser initiering når matchende trafikk dukker opp. Å skrive trap|start krever strongSwan 5.9.6 eller nyere, så sjekk versjonen før du kopierer linjen. dpd_action=restart ber om ny forhandling når peer-en erklæres død, og keyingtries=0 på tilkoblingsnivå tillater flere forsøk frem til suksess eller en permanent feil. Under IKEv2 har dpd_timeout ingen effekt i det hele tatt, fordi vanlig retransmisjon avgjør når peer-en ikke svarer.

Forsinkelsen i det eksempelet er et utgangspunkt og ikke en universell frist. Velg den ut fra hvor lang tid omstarten av peer-en tar, og hvor mye retransmisjon du er villig til å sitte gjennom.

Vit hvilken hendelse du gjenoppretter fra

Tre feil ser identiske ut på et dashbord og krever forskjellige innstillinger. En innledende tilkobling som aldri kom opp, er et konfigurasjons- eller tilgjengelighetsproblem. En peer som sluttet å svare, er DPD-tilfellet. Et child som peer-en lukket eksplisitt, er en policyhendelse med sin egen close_action, som DPD aldri observerer. Å lese loggen rundt avbruddet forteller deg hvilken av de tre du har, og svaret endrer rettelsen.

Ikke legg aggressiv re-initiering til en tilkobling som operatører lukker med vilje for vedlikehold, ellers dukker tunnelen opp midt i vinduet. For on-demand-design er en bevart trap nok, fordi matchende trafikk gjenoppretter child-et uten noen timer.

Verifiser ved navn, ikke ved daemon-status

Les tilkoblingen og child-et dens ved navn mens peer-en fortsatt er nede, og deretter igjen når den kommer tilbake; forskjellen mellom de to utskriftene er beviset.

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

Bekreft deretter tjenesten i stedet for assosiasjonen. En fersk child-sikkerhetsassosiasjon pluss en vellykket forespørsel til den private destinasjonen bak den er det faktaparet som betyr noe, og en kjørende daemon med en sunn urelatert tunnel beviser ingen av dem.

Hvis child-et aldri initierer, sjekk at testtrafikken samsvarer nøyaktig med de konfigurerte selektorene, inkludert protokoll og port. Hvis det initierer og feiler, les autentiserings- eller forslagsfeilen i stedet for å skjule den bak en endeløs løkke, fordi keyingtries=0 gjerne gjentar en permanent avvisning for alltid.

Last endringen i et vindu, og test på nytt

Reload er tryggere enn å restarte daemonen, og det er fortsatt ikke gratis: å erstatte eller losse et child kan lukke en startet assosiasjon eller miste trap-en.

Last inn i et vedlikeholdsvindu, behold forrige fil, og bekreft at tilkoblingen vises med innstillingene du hadde tenkt, og ikke med standardverdier.

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

Rull tilbake ved å gjenopprette forrige fil og laste den inn igjen, og gjenta deretter de samme to kommandoene. En tunnel som bare kommer tilbake etter en daemon-omstart, er ikke reparert, den er nullstilt.

Relaterte artikler