strongSwan ligger kvar nere efter peer-omstart: återställ en tunnel

Släpp daemon-omstarten. Lägg initiering och DPD på anslutningen som måste komma tillbaka, verifiera sedan vid namn och bevisa tjänsten, inte daemonen.

Fjärrgatewayen startar om, kommer tillbaka inom en minut, och den lokala strongSwan-daemonen fortsätter köra medan tunneln fortfarande ligger nere. Ett cron-jobb som greppar efter ESTABLISHED och startar om daemonen kommer till slut att dölja det, och det kommer också att avbryta varje orelaterad tunnel på maskinen medan det kanske missar den som faktiskt fallerade. Återställningen hör till anslutningen som måste komma tillbaka, uttryckt i inställningar som överlever en reload. Den här runbooken sätter upp det för en enda anslutning och bevisar resultatet vid namn.

Släpp den globala omstarten, behåll dess bevis

En daemon-omstart har två konkreta brister: den förstör tillståndet för varje anslutning, och den säger ingenting om vilken händelse som faktiskt fallerade. Statustexten du grep kan ha kommit från en annan anslutning, medan det nödvändiga child-et satt overksamt eftersom ingenting utlöste det.

Läs de inlästa anslutningarna och de aktiva associationerna innan du ändrar något, så att du har en förebild att jämföra med när peer-en kommer tillbaka.

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

Lägg initiering och omförsök på anslutningen som kommer tillbaka

I en swanctl.conf-utrullning ligger dessa inställningar på anslutnings- och child-nivå i stället för i en global policy. Fragmentet nedan är ett exempel från initiatorsidan som förutsätter att förslag, autentisering och selektorer redan är korrekta.

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

start_action avgör vad som händer när child-et läses in: start initierar direkt, medan trap installerar en policy som utlöser initiering när matchande trafik dyker upp. Att skriva trap|start kräver strongSwan 5.9.6 eller senare, så kontrollera versionen innan du kopierar raden. dpd_action=restart begär en ny förhandling när peer-en förklaras död, och keyingtries=0 på anslutningsnivå tillåter fler försök fram till framgång eller ett permanent fel. Under IKEv2 har dpd_timeout ingen effekt alls, eftersom vanlig omsändning avgör när peer-en inte svarar.

Fördröjningen i det exemplet är en utgångspunkt och inte en universell deadline. Välj den utifrån hur lång tid peer-ens omstart tar och hur mycket omsändning du är beredd att stå ut med.

Vet vilken händelse du återställer från

Tre fel ser identiska ut på en instrumentpanel och kräver olika inställningar. En inledande anslutning som aldrig kom upp är ett konfigurations- eller nåbarhetsproblem. En peer som slutade svara är DPD-fallet. Ett child som peer-en stängde explicit är en policyhändelse med egen close_action, som DPD aldrig observerar. Att läsa loggen kring avbrottet säger vilken av de tre du har, och svaret ändrar åtgärden.

Lägg inte till aggressiv återinitiering på en anslutning som operatörer stänger medvetet för underhåll, annars dyker tunneln upp igen mitt i fönstret. För on-demand-designer räcker en bevarad trap, eftersom matchande trafik återupprättar child-et utan någon timer.

Verifiera vid namn, inte vid daemonstatus

Läs anslutningen och dess child vid namn medan peer-en fortfarande ligger nere, och sedan igen när den kommer tillbaka; skillnaden mellan de två utskrifterna är beviset.

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

Bekräfta sedan tjänsten i stället för associationen. En ny child-säkerhetsassociation plus en lyckad förfrågan till det privata målet bakom den är det faktapar som betyder något, och en körande daemon med en frisk orelaterad tunnel bevisar ingen av dem.

Om child-et aldrig initierar, kontrollera att testtrafiken matchar de konfigurerade selektorerna exakt, inklusive protokoll och port. Om det initierar och misslyckas, läs autentiserings- eller förslagsfelet i stället för att gömma det bakom en oändlig loop, eftersom keyingtries=0 gärna upprepar en permanent avvisning för alltid.

Läs in ändringen i ett fönster och testa igen

Reload är säkrare än att starta om daemonen, och det är fortfarande inte gratis: att ersätta eller lossa ett child kan stänga en startad association eller tappa dess trap.

Läs in under ett underhållsfönster, behåll föregående fil och bekräfta att anslutningen visas med de inställningar du avsåg och inte med standardvärden.

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

Rulla tillbaka genom att återställa föregående fil och läsa in den igen, och upprepa sedan samma två kommandon. En tunnel som bara kommer tillbaka efter en daemon-omstart är inte reparerad, den är återställd.

Relaterade artiklar