Tormenta de reconexión na sucursal: límites de admisión de strongSwan

Observe como volve unha sucursal tras un fallo de enlace e a pasarela ve algo que nunca aparece nun día normal: decenas de portátiles chegan á vez desde unha única dirección pública. Cada un é un dispositivo lexítimo e cada un inicia un intercambio IKE que aínda non rematou. Que esa refaga teña éxito depende de límites que non teñen nada que ver con cantos empregados pode soportar o servidor. A refaga é curta, e é precisamente a carga de traballo para a que se construíu a ruta de admisión.

Siga un portátil de volta á rede

O cliente envía unha solicitude inicial e espera, e ata que o intercambio se completa a pasarela mantén o estado de admisión para ese intento. Outros dispositivos detrás da mesma dirección chegan mentres o primeiro aínda espera, e fan cola tras un límite que conta direccións en lugar de usuarios. Desde fóra, o síntoma é un feixe de usuarios que se conectan e un grupo maior que esgota o tempo.

Nada nesa secuencia é un fallo. É a ruta de admisión facendo o que se configurou para facer.

Conte o traballo semiaberto como un recurso propio

strongSwan separa dúas poboacións: asociacións plenamente establecidas e intentos que aínda se conectan ou esperan ser procesados. O limiar de bloqueo aplícase ás asociacións semiabertas atribuídas a unha dirección de par, e os limiares de cookie aplícanse globalmente e por dirección. Eses contadores protexen o daemon de ser consumido por traballo non autenticado, que é exactamente a forma dunha tormenta de reconexión. Nada dese estado aparece en unha lista de túneles establecidos.

Lelos como un tope das sesións de empregados é o erro que leva a subilo todo á vez. Un servidor que soporta catrocentos túneles establecidos non é automaticamente capaz de absorber catrocentos primeiros paquetes simultáneos, porque os dous custos recaen en lugares distintos.

A latencia de autenticación decide canto tempo permanece cada intento na conta de semiabertos. Un backend que responde amodo converte unha refaga curta nunha cola longa mesmo cando a taxa de chegada é modesta.

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

Lea os axustes de admisión antes de cambialos

Atope os valores que o daemon en execución cargou realmente antes de formarse unha opinión sobre eles. A configuración adoita repartirse entre un ficheiro principal e un directorio de fragmentos por complemento, así que un valor que fixe nun lugar pode quedar anulado noutro. A busca de abaixo mostra cada ficheiro que menciona eses axustes.

Despois decida que número é demasiado pequeno. Se unha dirección representa lexitimamente unha oficina enteira, o limiar de bloqueo por dirección é o valor que debe acoller esa concentración. Un limiar de cookie global protexe o daemon dunha inundación máis ampla e non debe relaxarse porque un sitio se reconecte. Compare ese valor por dirección co sitio máis grande que realmente teña.

Manteña activado o mecanismo de cookies. As cookies fan que o cliente demostre que pode recibir na dirección que afirma antes de que o daemon gaste traballo real no intercambio, e desactivalas non é unha mellora de capacidade neutra. Suba un limiar só cunha taxa de chegada medida e un orzamento de autenticación declarado detrás.

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

Planifique o regreso, non só o estado estacionario

Un obxectivo de dispoñibilidade que só conta sesións establecidas describe unha tarde tranquila, non unha recuperación. Pregúntese en cambio como regresa a poboación prevista tras un evento de rede compartido, e se a ruta de admisión pode absorber esa forma.

Escalonar a reconexión por unha frota xestionada adoita ser máis barato que ampliar os límites, porque elimina a refaga artificial en lugar de pagar por ela de forma permanente. Vixíe o estado semiaberto e os eventos de admisión xunto aos establecementos correctos, e trate un reconto semiaberto crecente con éxitos planos como unha advertencia temperá e non como unha curiosidade.

A referencia do provedor para estes axustes é a documentación de strongswan.conf, que nomea os contadores e a versión que introduciu o limiar de cookie por dirección. Lea a sección da súa versión instalada en lugar da páxina máis recente, porque os valores por defecto móvense entre versións.