IPsec-Overhead: Modus, NAT-T und Algorithmen verändern ihn
Eine einzige veröffentlichte Overhead-Zahl beschreibt eine Kapselung auf einem Pfad. Zählen Sie die Header zusammen, die Ihr Tunnel tatsächlich aushandelt, und messen Sie dann den Pfad.
Irgendwo in einer Anleitung steht eine Zahl, meist zwischen sechzig und achtzig Bytes, die jemand von 1500 abgezogen hat, um eine Interface-MTU zu erhalten. Diese Zahl beschreibt eine bestimmte Kapselung auf einem bestimmten Pfad. Ändern Sie den Modus, die äußere Adressfamilie, die Verschlüsselung oder das Vorhandensein von NAT, und die Rechnung gilt nicht mehr für Ihren Tunnel.
Die Zahl stammt aus einem anderen Tunnel
Overhead ist keine Eigenschaft von IPsec an sich. Er ist eine Eigenschaft des Pakets, das tatsächlich gebaut wird: ein ausgehandelter Modus, ein äußerer Header, ein Schutzheader, Padding, ein Integritätsfeld und möglicherweise eine zusätzliche UDP-Hülle.
Eine Zahl, die für den Transportmodus mit IPv4 und ohne NAT genannt wird, beschreibt ein kleineres Paket als der Tunnelmodus mit IPv6 unter NAT-Traversal. Beide sind für ihren eigenen Fall richtig. Eine davon in eine andere Umgebung zu kopieren, führt genau zu einer MTU, die große Übertragungen zerbricht. Der Fehler bleibt leise, weil kleine Anfragen weiter funktionieren.
Zählen Sie die Schichten zusammen, die wirklich da sind
Beginnen Sie beim äußeren IP-Header und arbeiten Sie sich nach innen. Im Tunnelmodus steckt das ursprüngliche Paket innen, der äußere Header ist also eine Ergänzung und kein Ersatz. RFC 4303 beschreibt den ESP-Header, das Padding und die Integritätsdaten, die darauf folgen.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
Keine dieser Zeilen ist über Umgebungen hinweg konstant, und die Padding-Zeile ist nicht einmal innerhalb einer Umgebung konstant. Genau deshalb enttäuscht eine einzelne veröffentlichte Overhead-Zahl.
Zwei Standorte können sich über denselben Tunnel uneinig sein
Das geschützte Paket muss trotzdem den äußeren Pfad überqueren, und der äußere Pfad ist nicht überall gleich. Eine PPPoE-Zugangsleitung trägt weniger als ein sauberes Ethernet-Segment. Ein Mobilfunknetz kann weiter schrumpfen, und ein Anbieter, der seinen eigenen Verkehr tunnelt, fügt eine weitere Kapselung hinzu, die niemand erwähnt hat. Ein Tunnel, der auf einem Link funktioniert und auf einem anderen scheitert, beschreibt den zweiten Link, nicht das Protokoll.
Auch die beiden Richtungen können sich unterscheiden. Eine asymmetrische Route kann einen funktionierenden Upload und einen stockenden Download liefern, was wie ein Anwendungsproblem aussieht, bis man auf Paketgrößen statt auf Erreichbarkeit schaut. Ein erfolgreicher kleiner Ping beweist sehr wenig über eine Antwort in voller Größe.
Messen statt abziehen
Finden Sie das größte Datagramm, das den Pfad übersteht. Vergleichen Sie es dann mit dem Wert, den die Schnittstelle meldet:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Gehen Sie mit der Ping-Größe herunter, bis Antworten ankommen, und behandeln Sie den größten funktionierenden Wert als das Budget für diesen Pfad. Die xfrm-Ausgabe sagt Ihnen, welcher Modus und welche Algorithmen ausgehandelt wurden, und das ist die Eingabe für jede ehrliche Berechnung. Der Mitschnitt bestätigt, ob ESP oder UDP-gekapseltes ESP auf der Leitung liegt, und das klärt die NAT-Frage ohne Raten.
Reservieren Sie auch einen Wert für die Steuerungsebene. IKE-Handshake-Pakete haben eine andere Struktur als Datenpakete, eine aus einem Handshake-Mitschnitt abgeleitete Größe ist also keine Data-Plane-MTU.
Setzen Sie die Zahl dorthin, wo sie hingehört
Für TCP durch einen Tunnel ist ein MSS-Clamp oft die am wenigsten invasive Kontrolle, weil er reduziert, was die Endpunkte senden, ohne den Tunnel selbst zu ändern. Bei einem routenbasierten Tunnel setzen Sie die MTU der Tunnelschnittstelle bewusst und dokumentieren, warum. Beides gleichzeitig zu tun und dann zu messen, sagt Ihnen nichts darüber, was geholfen hat.
Halten Sie den ausgehandelten Modus, die äußere Familie, die NAT-Bedingung und das reproduzierbare Symptom zusammen im Ticket fest. Ein aufgezeichneter Satz von vier Fakten schlägt eine erinnerte Konstante, und nur diese Version übersteht das nächste Client-Update.