TCP-MSS-Anpassung auf einem Linux-IPsec-Gateway: Was sie behebt

Ping funktioniert, SSH funktioniert, eine kleine Seite lädt, und dann hängt jede große Antwort, bis sie in ein Timeout läuft. Das klassische Muster deutet auf die Paketgröße und nicht auf die Erreichbarkeit hin: Der Pfad trägt den Handshake und die ersten paar Kilobyte, danach verschwindet ein Segment voller Größe. Auf einem Linux-IPsec-Gateway ist eine TCP-MSS-Regel oft die Lösung, aber nur, wenn Sie verstehen, was sie ändert und wo sich das Paket, das sie berührt, tatsächlich befindet. Die Reihenfolge unten folgt dem Paket vom Symptom bis zur Platzierung der Regel, sodass Sie aufhören können, sobald die Erklärung nicht mehr passt.

Das Symptom, das auf MSS hindeutet

TCP handelt im Handshake eine maximale Segmentgröße aus. Ist dieser Wert größer, als der Pfad nach der Kapselung tragen kann, erzeugt der Sender weiterhin Segmente, die nie ankommen, und die Verbindung bleibt nach dem ersten Hin- und Rückweg stehen. Kleine Antworten passen; große nicht.

ICMP-Rückmeldungen können die Verbindung über die Pfad-MTU-Erkennung retten, und eine Firewall, die diese Nachrichten verwirft, macht aus dem Hänger ein stilles schwarzes Loch. Deshalb funktioniert derselbe Tunnel für eine Anwendung und scheitert für eine andere, ohne dass sich die Konfiguration sichtbar unterscheidet.

Was eine TCPMSS-Regel tut und was nicht

Die Regel schreibt die MSS-Option in TCP-Handshake-Paketen im Vorbeigehen um. Sie setzt nicht die MTU der Tunnel-Schnittstelle, sie ändert nicht die IPsec-Richtlinie, und auf aktuellen Kernel-Versionen senkt sie einen angekündigten Wert nur, statt einen bereits kleineren zu erhöhen. Außerdem berührt sie nur TCP; UDP-Nutzlasten, das Verhalten von DNS und die ausgehandelten Traffic-Selectors liegen außerhalb ihrer Reichweite.

Weil die Änderung während des Handshakes geschieht, behält eine bestehende Verbindung, die vor der Regel aufgebaut wurde, ihren alten Wert. Testen Sie mit einer neuen Verbindung, und erwarten Sie, dass der erste Versuch nach der Änderung Ihnen überhaupt etwas sagt. Nichts an der Regel erreicht eine Verbindung, die bereits offen ist. Deshalb kann eine Lösung, die mitten in einem Vorfall angewendet wird, so aussehen, als hätte sie gar nichts bewirkt.

Regel auf den inneren TCP-Pfad setzen

Auf einem richtlinienbasierten Linux-Gateway sieht das weitergeleitete Paket für die Firewall noch wie gewöhnliches TCP aus. Die IPsec-Richtlinie entscheidet, dass das Paket geschützt wird; die Firewall sieht für den inneren Fluss keinen ESP-Header, sodass eine Übereinstimmung mit ESP hier ein völlig anderes Paket beschreibt. Diese Diskrepanz ist der Grund, warum manche Regeln korrekt erscheinen und nie greifen.

In iptables ausgedrückt gehört die Regel in die mangle-Tabelle auf dem Weiterleitungspfad, beschränkt auf Handshake-Pakete: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Die Zahl ist ein Beispiel und keine allgemeine Konstante; leiten Sie sie aus dem Kapselungs-Overhead und der tatsächlichen MTU des Pfads ab. Ein nftables-Äquivalent setzt die maximale Segmentgröße in einer forward- oder postrouting-Kette.

Halten Sie die äußeren Listener-Regeln für IKE und ESP getrennt von den inneren Weiterleitungsregeln. Eine einzige Regel, die sowohl den Anwendungsfluss als auch das äußere Protokoll autorisieren soll, trifft am Ende keines von beiden zuverlässig.

Eigentümer der Firewall und die NAT-Reihenfolge respektieren

Wenn UFW die Host-Firewall verwaltet, nehmen Sie die Änderungen an mangle und Weiterleitung über ihre unterstützte dauerhafte Konfiguration vor, statt einen Befehl einzutippen, der beim nächsten Neuladen verschwindet. Eine Regel, die in der falschen Tabelle oder hinter einer abschließenden Regel eingefügt wird, hat keine Wirkung, und die laufende Tabelle verbirgt das vor Ihnen.

Die Quellübersetzung ist eine separate Entscheidung, die oft mit dieser zusammenspielt. Eine Ausnahme, die vor einer allgemeinen Masquerade-Regel steht, verhindert, dass geschützter Verkehr die Quelle verliert, die seine Richtlinie verlangt; sie repariert kein Größenproblem, und eine Größenregel repariert kein Übersetzungsproblem.

Eng prüfen, dann aufhören

Öffnen Sie eine frische Verbindung zu dem Dienst, der scheitert, und beobachten Sie sowohl die Anwendung als auch die Zähler der Regel. Wenn der Hänger verschwindet, haben Sie einen Beleg über diesen TCP-Pfad mit dieser Kapselung. Sie haben keinen Beleg dafür, dass jedes VPN-Protokoll passt, dass jede UDP-Anwendung repariert ist oder dass ein bestimmter vorgelagerter Dienst die ursprüngliche Ursache war.

Lassen Sie die ICMP-Größenrückmeldung dort arbeiten, wo die Richtlinie es erlaubt, und behandeln Sie die automatische Anpassung anhand der Routen-MTU mit Vorsicht, wenn der äußere IPsec-Pfad nicht durch die innere Route abgebildet wird. Je enger die Schlussfolgerung, desto leichter ist der nächste Vorfall zu diagnostizieren.