Reconnect-Sturm in der Filiale: strongSwan-Aufnahmegrenzen

Beobachten Sie, wie eine Filiale nach einem Leitungsausfall zurückkehrt, und das Gateway sieht etwas, das an einem normalen Tag nie auftritt: Dutzende Laptops kommen gleichzeitig von einer einzigen öffentlichen Adresse. Jeder ist ein legitimes Gerät, und jeder beginnt einen IKE-Austausch, der noch nicht abgeschlossen ist. Ob dieser Schwall gelingt, hängt von Grenzen ab, die nichts damit zu tun haben, wie viele Mitarbeiter der Server tragen kann. Der Schwall ist kurz, und er ist genau die Arbeitslast, für die der Aufnahmepfad gebaut wurde.

Folgen Sie einem Laptop zurück ins Netz

Der Client sendet eine erste Anfrage und wartet, und bis der Austausch abgeschlossen ist, hält das Gateway den Aufnahmezustand für diesen Versuch. Andere Geräte hinter derselben Adresse treffen ein, während das erste noch wartet, und sie reihen sich hinter einer Grenze ein, die Adressen statt Benutzer zählt. Von außen ist das Symptom eine Handvoll Benutzer, die sich verbinden, und eine größere Gruppe, die in einen Timeout läuft.

Nichts in dieser Abfolge ist ein Fehler. Der Aufnahmepfad tut, wofür er konfiguriert wurde.

Halboffene Arbeit als eigene Ressource zählen

strongSwan trennt zwei Populationen: Assoziationen, die vollständig etabliert sind, und Versuche, die noch verbinden oder auf Bearbeitung warten. Die Blockschwelle gilt für halboffene Assoziationen, die einer Peer-Adresse zugeordnet sind, und die Cookie-Schwellen gelten global und pro Adresse. Diese Zähler schützen den Daemon davor, von nicht authentifizierter Arbeit verbraucht zu werden, was genau die Form eines Reconnect-Sturms ist. Nichts von diesem Zustand erscheint in einer Liste etablierter Tunnel.

Sie als Obergrenze für Mitarbeitersitzungen zu lesen, ist der Fehler, der dazu führt, alles auf einmal zu erhöhen. Ein Server, der vierhundert etablierte Tunnel trägt, kann nicht automatisch vierhundert gleichzeitige erste Pakete aufnehmen, weil die beiden Kosten an verschiedenen Stellen anfallen.

Die Authentifizierungslatenz entscheidet, wie lange jeder Versuch im Zähler der halboffenen bleibt. Ein Backend, das langsam antwortet, verwandelt einen kurzen Schwall in eine lange Warteschlange, selbst wenn die Ankunftsrate bescheiden ist.

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

Lesen Sie die Aufnahmeeinstellungen, bevor Sie sie ändern

Finden Sie die Werte, die der laufende Daemon tatsächlich geladen hat, bevor Sie sich eine Meinung darüber bilden. Die Konfiguration ist oft auf eine Hauptdatei und ein Verzeichnis mit Snippets pro Plugin verteilt, sodass ein an einer Stelle gesetzter Wert an anderer Stelle überschrieben werden kann. Die Suche unten zeigt jede Datei, die diese Einstellungen erwähnt.

Entscheiden Sie dann, welche Zahl zu klein ist. Wenn eine Adresse legitim ein ganzes Büro repräsentiert, ist die Blockschwelle pro Adresse der Wert, der diese Konzentration aufnehmen muss. Eine globale Cookie-Schwelle schützt den Daemon vor einer breiteren Flut und sollte nicht gelockert werden, weil ein Standort sich neu verbindet. Vergleichen Sie diesen Wert pro Adresse mit dem größten Standort, den Sie tatsächlich haben.

Lassen Sie den Cookie-Mechanismus aktiviert. Cookies bringen einen Client dazu, zu beweisen, dass er an seiner behaupteten Adresse empfangen kann, bevor der Daemon echte Arbeit in den Austausch steckt, und sie zu deaktivieren ist kein neutrales Kapazitätsupgrade. Erhöhen Sie eine Schwelle nur mit einer gemessenen Ankunftsrate und einem erklärten Authentifizierungsbudget dahinter.

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

Planen Sie die Rückkehr, nicht nur den Dauerzustand

Ein Verfügbarkeitsziel, das nur etablierte Sitzungen zählt, beschreibt einen ruhigen Nachmittag, keine Wiederherstellung. Fragen Sie stattdessen, wie die vorgesehene Population nach einem gemeinsamen Netzwerkereignis zurückkehrt und ob der Aufnahmepfad diese Form aufnehmen kann.

Das Verteilen der Wiederverbindung über eine verwaltete Flotte ist oft billiger als das Vergrößern von Grenzen, weil es den künstlichen Schwall entfernt, statt dauerhaft dafür zu zahlen. Überwachen Sie den halboffenen Zustand und Aufnahmeereignisse neben erfolgreichen Etablierungen und behandeln Sie einen steigenden Zähler halboffener Verbindungen bei flachen Erfolgen als frühe Warnung statt als Kuriosität.

Die Herstellerreferenz für diese Einstellungen ist die strongswan.conf-Dokumentation, die die Zähler und die Version nennt, die die Cookie-Schwelle pro Adresse eingeführt hat. Lesen Sie den Abschnitt für Ihre installierte Version statt die neueste Seite, weil sich Standardwerte zwischen Versionen verschieben.