Ein festes inneres Paket mit 1,500 Bytes durch ein VPN tragen

Sie haben eine Anforderung, die sich nicht verbiegen lässt: Die Gegenseite muss dasselbe 1,500-Byte-IP-Paket empfangen, das der Absender aussendet, Header eingeschlossen. Ein Tunnel kann dieses Paket plus seine eigene Rahmung nicht in ein zweites 1,500-Byte-IP-Paket packen, also muss etwas am Design nachgeben. Die Reihenfolge unten ist die, die ich in einem Änderungsfenster verwende: das Byte-Budget aufschreiben, belegen, was das Underlay tatsächlich tragen kann, dann genau einen Transportmechanismus wählen und das innere Paket auf der Gegenseite bestätigen.

Schreiben Sie das Byte-Budget, bevor Sie ein Profil bearbeiten

Kapselung fügt auf mehreren Ebenen Bytes hinzu, und die Summe ist eine Eigenschaft Ihres Profils und keine Konstante zum Nachschlagen. Adressfamilie, Cipher-Wahl, Transportprotokoll und jede Kompressions- oder Rahmungsoption verschieben die Zahl, weshalb eine aus einem anderen Deployment kopierte Subtraktion als Budget wertlos ist. Beginnen Sie mit der inneren Anforderung, addieren Sie den gemessenen Overhead pro Paket Ihrer eigenen Konfiguration und schreiben Sie die resultierende äußere Größe auf das Änderungsticket, bevor jemand eine Datei bearbeitet.

Zwei Zahlen entscheiden das Design: das größte äußere Paket, das der Pfad ohne Fragmentierung trägt, und die zusätzlichen Bytes, die Ihre Kapselung braucht. Ist die erste kleiner als die zweite plus 1,500, muss sich eine von beiden ändern. Die Wahl ist dann eng statt kreativ, weshalb ich beide Zahlen notiere, bevor wir Optionen diskutieren. Nichts auf der Tunnel-Ebene komprimiert diese Bytes weg, und keine einzelne MTU-Zahl hebt die Anforderung auf, die Sie bekommen haben.

Prüfen Sie das Underlay mit Do-not-fragment-Pings

Messen Sie den Pfad, statt der Interface-MTU zu vertrauen, denn das kleinste Glied im äußeren Pfad zählt. Unter Linux setzt -M do das Do-not-fragment-Bit, und -s nimmt die ICMP-Nutzlast, sodass ein 1,500-Byte-Frame bei 1,472 Byte Nutzlast antwortet, nachdem die 20-Byte-IP-Header und der 8-Byte-ICMP-Header abgezogen sind. Gehen Sie mit der Nutzlast nach oben, bis die Probe scheitert, und springen Sie dann auf eine Jumbo-Größe, um zu sehen, ob der Pfad sie überhaupt trägt.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Ein Pfad, der 1,472 durchlässt und bei 8,972 scheitert, kann ein inneres Paket von 1,500 Bytes plus Overhead nicht in einem einzigen äußeren Paket tragen. Das ist die Antwort, die Sie brauchten, bevor Sie die VPN-Konfiguration öffnen. Sie entscheidet auch, welcher der nächsten beiden Abschnitte für Sie gilt, also halten Sie beide Prüfergebnisse neben dem Ticket. Raten kostet hier ein Wartungsfenster, denn ein Tunnel, der sich als aktiv meldet, sagt nichts über das größte Paket, das der Pfad annimmt.

Heben Sie die Pfad-MTU nur an, wo jeder Hop zustimmt

Jumbo-Frames sind eine Ende-zu-Ende-Eigenschaft, keine Einstellung, die Sie auf den zwei Endpunkten aktivieren, die Sie zufällig kontrollieren. Jeder Switch, Router und Provider-Übergabepunkt auf dem äußeren Pfad muss der größeren Größe zustimmen, und ein einziger Hop mit 1,500 Bytes verwirft still das Paket, das Sie gerade größer gemacht haben. Nur das lokale Interface anzuheben ist die klassische halbe Änderung, durch die der Tunnel kaputt aussieht, während das Underlay leise verwirft.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Ändern Sie das Interface und prüfen Sie dann denselben Pfad erneut, bevor Sie etwas anderes ändern. Scheitert die Probe weiterhin, machen Sie es mit ip link set dev eth1 mtu 1500 rückgängig und wechseln Sie zur Fragmentierung, statt mit einem Provider über ein Glied zu streiten, das Ihnen nicht gehört.

Nutzen Sie Tunnel-Fragmentierung, wenn das Underlay nicht wachsen kann

Ein unterstützter Fragmentierungsmechanismus unterhalb des inneren Pakets erlaubt mehreren äußeren Paketen, ein inneres Paket zu tragen, und der entfernte Tunnelendpunkt setzt sie wieder zusammen, bevor er das Original nach oben durchreicht. Die UDP-Fragment-Option von Community OpenVPN ist eine Umsetzung dieser Idee und nicht dasselbe wie gewöhnliche IP-Fragmentierung des äußeren Pakets. Beide Seiten müssen eine Version betreiben, die das Format unterstützt, und der Datenpfad muss der sein, den Sie vermuten: OpenVPN-3-Clients und kernelbeschleunigte Datenkanäle haben unterschiedliche Grenzen, sodass ein Profil, das auf einem Client funktioniert, auf einem anderen scheitern kann.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Gewöhnliche äußere Fragmentierung ist die andere Option, und sie ist die schwächere. IPv6-Router fragmentieren ein weitergeleitetes Paket überhaupt nicht, ein übergroßes äußeres Paket stirbt also einfach, und der Absender erfährt davon nur, wenn die betreffende ICMPv6-Nachricht den Pfad überlebt. Fragmente laden zudem Filterung und Verlustverstärkung ein, weshalb ich das als Rückfallebene und nicht als Plan behandle.

Ein streambasierter äußerer Träger umgeht die Größenfrage, indem er seinen eigenen Bytestrom segmentiert, und das rekonstruierte innere Paket kann weiterhin 1,500 Bytes groß sein. Das ist eine Transportentscheidung mit eigenen Kosten, einschließlich des bekannten Verhaltens von TCP in TCP, also treffen Sie sie bewusst und nicht als Nebenwirkung einer MTU-Diskussion.

Bestätigen Sie, dass das innere Paket unverändert ankommt

Verifikation ist kein erfolgreicher Handshake. Erfassen Sie an beiden Enden auf dem Tunnel-Interface und vergleichen Sie Größe und Inhalt des Pakets, das die Anwendung tatsächlich gesendet hat, mit dem, das die Gegenseite empfangen hat.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Zeigt die Aufzeichnung auf der Gegenseite das innere Paket in voller Größe, funktioniert die Transportwahl, und es bleibt nur, sie festzuhalten. Zeigt sie nichts, während der Tunnel sich als aktiv meldet, wird das äußere Paket irgendwo zwischen den Endpunkten verworfen, was Sie zurück zur Probe schickt und nicht zu den Cipher-Einstellungen.

Notieren Sie drei Dinge im Ticket, bevor Sie es schließen: das gemessene äußere Budget, den gewählten Mechanismus und den Befehl, der bewiesen hat, dass das innere Paket überlebt hat. Die nächste Person an diesem Tunnel braucht alle drei, und keines davon lässt sich allein aus der Konfigurationsdatei rekonstruieren.