Tempête de reconnexion au bureau distant : limites d'admission de strongSwan

Regardez un bureau distant revenir après une panne de liaison et la passerelle voit quelque chose qui n'apparaît jamais un jour normal : des dizaines d'ordinateurs portables arrivent en même temps depuis une seule adresse publique. Chacun est un appareil légitime et chacun lance un échange IKE qui n'est pas encore terminé. La réussite de cette rafale dépend de limites qui n'ont rien à voir avec le nombre d'employés que le serveur peut porter. La rafale est courte, et c'est précisément la charge de travail pour laquelle le chemin d'admission a été construit.

Suivez un ordinateur portable qui revient sur le réseau

Le client envoie une demande initiale et attend, et tant que l'échange n'est pas terminé la passerelle conserve l'état d'admission pour cette tentative. D'autres appareils derrière la même adresse arrivent pendant que le premier attend encore, et ils font la queue derrière une limite qui compte les adresses plutôt que les utilisateurs. Vu de l'extérieur, le symptôme est une poignée d'utilisateurs qui se connectent et un groupe plus large qui expire.

Rien dans cette séquence n'est un défaut. C'est le chemin d'admission qui fait ce pour quoi il a été configuré.

Comptez le travail semi-ouvert comme une ressource à part

strongSwan sépare deux populations : les associations pleinement établies et les tentatives qui se connectent encore ou attendent d'être traitées. Le seuil de blocage s'applique aux associations semi-ouvertes attribuées à une adresse de pair, et les seuils de cookie s'appliquent globalement et par adresse. Ces compteurs protègent le démon d'être consumé par du travail non authentifié, ce qui est exactement la forme d'une tempête de reconnexion. Rien de cet état n'apparaît dans une liste de tunnels établis.

Les lire comme un plafond des sessions d'employés est l'erreur qui conduit à tout augmenter d'un coup. Un serveur qui porte quatre cents tunnels établis n'est pas automatiquement capable d'absorber quatre cents premiers paquets simultanés, parce que les deux coûts tombent à des endroits différents.

La latence d'authentification décide combien de temps chaque tentative reste dans le décompte des semi-ouvertes. Un backend qui répond lentement transforme une rafale courte en une longue file même lorsque le taux d'arrivée est modeste.

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

Lisez les réglages d'admission avant de les modifier

Trouvez les valeurs que le démon en cours d'exécution a réellement chargées avant de vous en faire une opinion. La configuration est souvent répartie entre un fichier principal et un répertoire d'extraits par plugin, si bien qu'une valeur définie à un endroit peut être écrasée ailleurs. La recherche ci-dessous montre chaque fichier qui mentionne ces réglages.

Décidez ensuite quel nombre est trop petit. Si une adresse représente légitimement un bureau entier, le seuil de blocage par adresse est la valeur qui doit accueillir cette concentration. Un seuil de cookie global protège le démon contre une inondation plus large et ne doit pas être assoupli parce qu'un site se reconnecte. Comparez cette valeur par adresse au plus grand site que vous avez réellement.

Gardez le mécanisme de cookies activé. Les cookies obligent un client à prouver qu'il peut recevoir à l'adresse qu'il revendique avant que le démon ne consacre du vrai travail à l'échange, et les désactiver n'est pas une mise à niveau de capacité neutre. N'augmentez un seuil qu'avec un taux d'arrivée mesuré et un budget d'authentification annoncé derrière.

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

Planifiez le retour, pas seulement l'état stable

Un objectif de disponibilité qui ne compte que les sessions établies décrit un après-midi calme, pas une reprise. Demandez plutôt comment la population visée revient après un événement réseau partagé, et si le chemin d'admission peut absorber cette forme.

Étaler la reconnexion sur une flotte gérée est souvent moins cher que d'agrandir les limites, car cela supprime la rafale artificielle au lieu de la payer en permanence. Surveillez l'état semi-ouvert et les événements d'admission à côté des établissements réussis, et traitez un décompte semi-ouvert qui monte avec des succès stables comme un avertissement précoce plutôt que comme une curiosité.

La référence du fournisseur pour ces réglages est la documentation de strongswan.conf, qui nomme les compteurs et la version qui a introduit le seuil de cookie par adresse. Lisez la section de votre version installée plutôt que la page la plus récente, car les valeurs par défaut bougent entre les versions.