Tempestade de reconexão na filial: limites de admissão do strongSwan

Observe uma filial voltar após uma falha de link e o gateway vê algo que nunca aparece num dia normal: dezenas de laptops chegam ao mesmo tempo de um único endereço público. Cada um é um dispositivo legítimo e cada um inicia uma troca IKE que ainda não terminou. Se essa rajada terá sucesso depende de limites que nada têm a ver com quantos funcionários o servidor consegue suportar. A rajada é curta, e é exatamente a carga de trabalho para a qual o caminho de admissão foi construído.

Siga um laptop de volta à rede

O cliente envia uma solicitação inicial e espera, e até a troca ser concluída o gateway mantém o estado de admissão para essa tentativa. Outros dispositivos atrás do mesmo endereço chegam enquanto o primeiro ainda espera, e ficam na fila atrás de um limite que conta endereços em vez de usuários. De fora, o sintoma é um punhado de usuários que se conectam e um grupo maior que esgota o tempo.

Nada nessa sequência é uma falha. É o caminho de admissão fazendo o que foi configurado para fazer.

Conte o trabalho semiaberto como um recurso próprio

O strongSwan separa duas populações: associações plenamente estabelecidas e tentativas que ainda se conectam ou esperam processamento. O limite de bloqueio aplica-se às associações semiabertas atribuídas a um endereço de par, e os limites de cookie aplicam-se globalmente e por endereço. Esses contadores protegem o daemon de ser consumido por trabalho não autenticado, que é exatamente a forma de uma tempestade de reconexão. Nada desse estado aparece em uma lista de túneis estabelecidos.

Lê-los como um teto das sessões de funcionários é o erro que leva a aumentar tudo de uma vez. Um servidor que carrega quatrocentos túneis estabelecidos não é automaticamente capaz de absorver quatrocentos primeiros pacotes simultâneos, porque os dois custos caem em lugares diferentes.

A latência de autenticação decide quanto tempo cada tentativa permanece na contagem de semiabertos. Um backend que responde devagar transforma uma rajada curta numa fila longa mesmo quando a taxa de chegada é modesta.

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

Leia as configurações de admissão antes de alterá-las

Encontre os valores que o daemon em execução realmente carregou antes de formar uma opinião sobre eles. A configuração costuma ser dividida entre um arquivo principal e um diretório de fragmentos por plugin, então um valor definido num lugar pode ser substituído noutro. A busca abaixo mostra cada arquivo que menciona essas configurações.

Depois decida qual número é pequeno demais. Se um endereço representa legitimamente um escritório inteiro, o limite de bloqueio por endereço é o valor que deve acomodar essa concentração. Um limite de cookie global protege o daemon de uma inundação mais ampla e não deve ser afrouxado porque um site se reconecta. Compare esse valor por endereço com o maior site que você realmente tem.

Mantenha o mecanismo de cookies ativado. Os cookies obrigam um cliente a provar que consegue receber no endereço que alega antes de o daemon gastar trabalho real na troca, e desativá-los não é uma atualização de capacidade neutra. Aumente um limite apenas com uma taxa de chegada medida e um orçamento de autenticação declarado por trás.

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

Planeje o retorno, não apenas o estado estacionário

Uma meta de disponibilidade que conta apenas sessões estabelecidas descreve uma tarde tranquila, não uma recuperação. Pergunte, em vez disso, como a população pretendida volta após um evento de rede compartilhado, e se o caminho de admissão consegue absorver esse formato.

Escalonar a reconexão por uma frota gerenciada costuma ser mais barato do que ampliar os limites, porque remove a rajada artificial em vez de pagar por ela permanentemente. Monitore o estado semiaberto e os eventos de admissão ao lado dos estabelecimentos bem-sucedidos, e trate uma contagem semiaberta crescente com sucessos estáveis como um alerta precoce, não como uma curiosidade.

A referência do fornecedor para essas configurações é a documentação do strongswan.conf, que nomeia os contadores e a versão que introduziu o limite de cookie por endereço. Leia a seção da sua versão instalada em vez da página mais recente, porque os padrões mudam entre versões.