strongSwan fica em baixo após o reinício do peer: recuperar um túnel

O gateway remoto reinicia, volta dentro de um minuto, e o daemon strongSwan local continua a correr com o túnel ainda em baixo. Uma tarefa cron que faz grep de ESTABLISHED e reinicia o daemon acabará por mascarar isso, e também vai interromper todos os túneis não relacionados na máquina, podendo até perder o que falhou. A recuperação pertence à ligação que tem de voltar, expressa em definições que sobrevivem a um reload. Este runbook prepara isso para uma única ligação e prova o resultado por nome.

Abandone o reinício global, guarde as suas provas

Um reinício do daemon tem dois defeitos concretos: destrói o estado de todas as ligações e não lhe diz nada sobre que evento falhou realmente. O texto de estado que pesquisou pode ter vindo de outra ligação, enquanto o child necessário ficou inativo porque nada o ativou.

Leia as ligações carregadas e as associações ativas antes de mudar seja o que for, para ter uma imagem de antes com que comparar quando o peer voltar.

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

Coloque a iniciação e as novas tentativas na ligação que volta

Numa implementação com swanctl.conf estas definições vivem ao nível da ligação e do child, e não numa política global. O fragmento abaixo é um exemplo do lado do iniciador que assume que as propostas, a autenticação e os seletores já estão corretos.

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

start_action decide o que acontece quando o child é carregado: start inicia imediatamente, enquanto trap instala uma política que desencadeia a iniciação quando aparece tráfego correspondente. Escrever trap|start exige strongSwan 5.9.6 ou posterior, por isso verifique a versão antes de copiar a linha. dpd_action=restart pede uma nova negociação assim que o peer é declarado morto, e keyingtries=0 ao nível da ligação permite mais tentativas até ao sucesso ou a um erro permanente. Com IKEv2, dpd_timeout não tem qualquer efeito, porque é a retransmissão normal que decide quando o peer não responde.

O atraso nesse exemplo é um ponto de partida e não um prazo universal. Escolha-o em função de quanto demora o reinício do peer e de quanta retransmissão está disposto a suportar.

Saiba de que evento está a recuperar

Três falhas parecem idênticas num painel e exigem definições diferentes. Uma ligação inicial que nunca subiu é um problema de configuração ou de acessibilidade. Um peer que deixou de responder é o caso DPD. Um child que o peer fechou explicitamente é um evento de política com o seu próprio close_action, que o DPD nunca observa. Ler o registo em torno da interrupção diz-lhe qual dos três tem, e a resposta muda a correção.

Não acrescente reinício agressivo a uma ligação que os operadores fecham de propósito para manutenção, ou o túnel reaparece a meio da janela. Para conceções a pedido basta um trap conservado, porque o tráfego correspondente restabelece o child sem qualquer temporizador.

Verifique por nome, não pelo estado do daemon

Leia a ligação e o seu child por nome enquanto o peer ainda está em baixo, e depois outra vez quando ele volta; a diferença entre essas duas saídas é a prova.

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

Depois confirme o serviço e não a associação. Uma associação de segurança child nova mais um pedido bem-sucedido ao destino privado por trás dela são o par de factos que importa, e um daemon a correr com um túnel não relacionado saudável não prova nenhum dos dois.

Se o child nunca iniciar, verifique se o tráfego de teste corresponde exatamente aos seletores configurados, incluindo protocolo e porta. Se iniciar e falhar, leia o erro de autenticação ou de proposta em vez de o esconder atrás de um ciclo infinito, porque keyingtries=0 repetirá de bom grado uma rejeição permanente para sempre.

Carregue a alteração numa janela e volte a testar

Recarregar é mais seguro do que reiniciar o daemon, e mesmo assim não é gratuito: substituir ou descarregar um child pode fechar uma associação já iniciada ou derrubar o seu trap.

Carregue durante uma janela de manutenção, guarde o ficheiro anterior e confirme que a ligação aparece com as definições que pretendia e não com os valores predefinidos.

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

Reverta restaurando o ficheiro anterior e carregando-o de novo, e depois repita os mesmos dois comandos. Um túnel que só volta após um reinício do daemon não está reparado, está reiniciado.