Warum ein ausgelasteter IPsec-Tunnel früh umschlüsselt: Zeit- und Volumengrenzen

Etwa alle fünfzig Minuten fällt ein Tunnel auf einer ausgelasteten Strecke für einige Sekunden aus, und der erste Verdächtige ist die Uhr. Associations können an einer Zeitgrenze oder an einer Byte-Zahl enden, und welche Grenze zuerst eintrifft, verabschiedet sie in den Ruhestand. Auf einer Strecke mit echtem Verkehr kann eine Volumengrenze lange vor Ablauf der konfigurierten Stunde greifen. Also ist „zu früh“ eine Aussage über die Uhr, nicht über die Association.

Zählen Sie, was die Association zählt, nicht die Schnittstelle

Eine Byte-Summe der Schnittstelle, der kombinierte Durchsatz eines Dashboards und der eigene Zähler der Association sind drei getrennte Zahlen, und nur eine davon wird mit dem Limit verglichen. Erfassen Sie die eingehende und die ausgehende Association getrennt mit ihren Bezeichnern, damit ein Schlüsselwechsel, der eine Richtung betrifft, als gerichtetes Ereignis erscheint statt als Rätsel. Der Zähler der Association beginnt beim Schlüsselwechsel ebenfalls neu, weshalb eine von der Schnittstelle genommene Summe wächst, während der maßgebliche Wert zurückgesetzt wird.

Die Rechnung lohnt sich einmal, damit die Größenordnung aufhört, sich willkürlich anzufühlen. Ein gezähltes Budget von einem Gibibyte, das mit stetigen 128 Mebibyte pro Minute abfließt, ist nach acht Minuten erschöpft, und das ist eine Einheitenumrechnung und keine Messung Ihres Tunnels. Liegt die resultierende Zahl weit unter der Zeitgrenze, ist das Volumen der Mechanismus, und kein Uhrenbeobachten erklärt das Intervall. Liegt sie weit darüber, ist die Byte-Grenze nicht Ihr Auslöser, und die Suche gehört woandershin.

Weiche und harte Schwellen sind zwei verschiedene Ereignisse

Eine weiche Schwelle verlangt einen Ersatz lange bevor die harte Grenze die Association beendet, und Implementierungen legen eigene Margen und Randomisierung über das, was Sie konfiguriert haben. Deshalb ist das beobachtete Intervall fast nie eine runde Zahl. Die IPsec-Architektur beschreibt Lebensdauern als Zeit- und Byte-Werte mit den beiden Schwellenarten, und der frühere Ablauf gilt. Behandeln Sie eine gedruckte Lebensdauer als Zeitplan, und Sie liegen um die Marge daneben.

Lesen Sie die effektive Richtlinie aus dem Laufzeitzustand, statt sie aus einer Zahl in einer Datei abzuleiten, denn die Marge gehört der Implementierung, nicht Ihrer Absicht. Widerstehen Sie der Versuchung, Grenzen bis zu ihrem Maximum zu dehnen, um das Symptom zu dämpfen: Ein Tunnel, der planmäßig umschlüsselt, verhält sich wie entworfen, und eine längere Lebensdauer verschiebt das Ereignis nur und hält einen kompromittierten Schlüssel länger nutzbar. Wenn der Ersatz selbst scheitert, ist die Grenze der Bote und nicht der Fehler.

Lesen Sie die effektive Lebensdauer aus dem Laufzeitzustand

Auf strongSwan gibt swanctl --list-sas die Zusammenfassung der Association mit ihren Schlüsselwechsel- und Lebensdauerzeiten aus, sodass der Wert, den der Daemon durchsetzen will, ohne Raten sichtbar ist. Auf einem Linux-Host ohne Daemon-Ansicht meldet ip xfrm state die konfigurierten weichen und harten Byte- und Paketgrenzen neben den aktuellen Zählern. Diese beiden Lesungen beantworten verschiedene Fragen, und beide gehören in das Ticket.

swanctl --list-sas
ip -s xfrm state

Vergleichen Sie die gedruckte weiche Schwelle mit dem gemessenen Intervall, denn ein Ersatz, der mit einer Marge unter der harten Grenze beginnt, ist normal, und einer, der nie beginnt, nicht. Zeigt der Daemon eine Lebensdauer und der Kernelzustand eine andere, blicken Sie auf zwei Schichten, die nicht übereinstimmen, und das ist selbst der Befund.

Beobachten Sie den Austausch, der die SA ersetzt

Halten Sie die drei Erneuerungen getrennt, denn sie scheitern auf verschiedene Weise: Ein Schlüsselwechsel der IKE SA baut eine neue Steuer-Association auf, ein Schlüsselwechsel der CHILD SA ersetzt die Daten-Association, und eine erneute Authentifizierung wiederholt den Identitätsaustausch. In IKEv2 entscheidet jeder Peer über seine eigenen Lebensdauern, statt einen gemeinsamen Wert auszuhandeln, daher ist ein Austausch, den Sie nicht angestoßen haben, normal. Eine Abweichung bei perfect forward secrecy ist ein häufiger Grund, warum eine neue child SA genau im Schlüsselwechselintervall stirbt, und es sieht genau wie ein Timerfehler aus, bis jemand den Vorschlag liest.

Vergleichen Sie die alte Association mit ihrer Nachfolgerin und mit dem Austausch, der sie hervorbrachte. Ein verschwindender Bezeichner ist routinehafter Ersatz; ein abgelehnter Vorschlag, eine fehlende Antwort oder das Fehlen nutzbaren Nachfolgezustands ist ein anderes Ereignis mit einem anderen Verantwortlichen. Bewahren Sie diese Belege, bevor Sie irgendetwas ändern, denn die versionsspezifischen Notizen, der Vorschlag der Gegenseite und die ausgehandelten Lebensdauern sind es, die den Fall eine Woche später lesbar machen, nachdem die Logs rotiert sind.

Belegen Sie die Erneuerung, statt sie zu verbergen

Abnehmen sollten Sie den Rollout, indem Sie eine geplante Erneuerung durchlaufen, nicht eine, die Ihnen zustößt. Erzwingen Sie einen einzelnen Schlüsselwechsel innerhalb eines Wartungsfensters, und bestätigen Sie dann, dass beide Richtungen danach Daten tragen und das Anwendungsergebnis unverändert ist, nicht bloß, dass die Tunnelanzeige grün ist. Notieren Sie, welche Grenze ausgelöst hat und welcher Austausch beteiligt war.

Eine Schlussfolgerung dieser Form hält einer Prüfung stand, ein geänderter Timerwert, der die Verbindung einen Nachmittag lang ruhig aussehen ließ, nicht. Wenn sich nur der Timer bewegt hat, sind die Belege mitgewandert.