strongSwan queda abaixo tras reiniciar o peer: recupera un túnel

Deixa o reinicio do daemon. Pon a iniciación e o DPD na conexión que debe volver, e despois verifica por nome e demostra o servizo, non o daemon.

A pasarela remota reiníciase, volve nun minuto, e o daemon strongSwan local segue executándose co túnel aínda abaixo. Unha tarefa de cron que busca ESTABLISHED e reinicia o daemon acabará tapando iso, e tamén interromperá todos os túneles non relacionados da máquina mentres quizais perde o que fallou. A recuperación pertence á conexión que ten que volver, expresada en axustes que sobreviven a unha recarga. Este runbook prepara iso para unha soa conexión e demostra o resultado por nome.

Retira o reinicio global, conserva as súas probas

Un reinicio do daemon ten dous defectos concretos: destrúe o estado de cada conexión e non che di nada sobre que evento fallou en realidade. O texto de estado que buscaches puido vir doutra conexión, mentres que o child necesario quedou inactivo porque nada o activou.

Le as conexións cargadas e as asociacións activas antes de cambiar nada, para teres unha imaxe previa coa que comparar cando o peer volva.

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

Pon a iniciación e os reintentos na conexión que volve

Nun despregue con swanctl.conf estes axustes viven a nivel de conexión e de child, non nunha política global. O fragmento de abaixo é un exemplo do lado do iniciador que dá por feito que as propostas, a autenticación e os selectores xa son correctos.

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

start_action decide que ocorre ao cargar o child: start inicia de inmediato, mentres que trap instala unha política que dispara a iniciación cando aparece tráfico coincidente. Escribir trap|start require strongSwan 5.9.6 ou posterior, así que comproba a versión antes de copiar a liña. dpd_action=restart pide unha negociación nova en canto o peer se declara morto, e keyingtries=0 a nivel de conexión permite máis intentos ata o éxito ou un erro permanente. Con IKEv2, dpd_timeout non ten ningún efecto, porque a retransmisión ordinaria decide cando o peer non responde.

O atraso dese exemplo é un punto de partida e non un prazo universal. Escólleo segundo canto tarda o reinicio do peer e canta retransmisión estás disposto a aguantar.

Sabe de que evento te recuperas

Tres fallos parecen idénticos nun panel e necesitan axustes distintos. Unha conexión inicial que nunca subiu é un problema de configuración ou de accesibilidade. Un peer que deixou de responder é o caso DPD. Un child que o peer pechou explicitamente é un evento de política co seu propio close_action, que o DPD nunca observa. Ler o rexistro arredor do corte diche cal dos tres tes, e a resposta cambia a solución.

Non engadas reinicio agresivo a unha conexión que os operadores pechan a propósito para mantemento, ou o túnel reaparecerá no medio da ventá. Para deseños baixo demanda abonda un trap conservado, porque o tráfico coincidente restablece o child sen ningún temporizador.

Verifica por nome, non polo estado do daemon

Le a conexión e o seu child por nome mentres o peer segue abaixo, e logo outra vez cando volve; a diferenza entre esas dúas saídas é a proba.

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

Despois confirma o servizo e non a asociación. Unha asociación de seguridade child nova máis unha petición correcta ao destino privado que hai detrás son o par de feitos que importa, e un daemon en marcha cun túnel non relacionado san non demostra ningún dos dous.

Se o child nunca inicia, comproba que o tráfico de proba coincida exactamente cos selectores configurados, incluídos protocolo e porto. Se inicia e falla, le o erro de autenticación ou de proposta en lugar de agochalo detrás dun bucle sen fin, porque keyingtries=0 repetirá un rexeitamento permanente para sempre.

Carga o cambio nunha ventá e volve probar

Recargar é máis seguro que reiniciar o daemon, e aínda así non é gratis: substituír ou descargar un child pode pechar unha asociación iniciada ou tirar o seu trap.

Carga durante unha ventá de mantemento, conserva o ficheiro anterior e confirma que a conexión aparece cos axustes que querías e non cos predeterminados.

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

Reverte restaurando o ficheiro anterior e cargándoo de novo, e despois repite os mesmos dous comandos. Un túnel que só volve tras reiniciar o daemon non está reparado, está reiniciado.

Artigos relacionados