Wer die WireGuard-MTU wählt: wg-quick, der Kernel oder du

WireGuard kennt keine MTU-Aushandlung. Es verschlüsselt, was ihm die Schnittstelle übergibt, und sendet das Ergebnis, und wenn das gekapselte Paket den Pfad überschreitet, wird es irgendwo verworfen oder fragmentiert, wo du es nicht siehst. Jemand muss die MTU der Schnittstelle wählen, und dieser Jemand ist das Werkzeug, das die Schnittstelle hochgebracht hat.

Es gibt drei Kandidaten, und sie sind leicht zu verwechseln.

Drei Stellen, von denen der Wert kommen kann

Der Wert kann ausdrücklich in der Schnittstellenkonfiguration gesetzt, vom Einrichtungswerkzeug aus Routinginformationen berechnet oder von dem Netzwerkmanager gesetzt werden, dem die Schnittstelle gehört. Ein einfacher Aufruf von wg tut nichts davon, weil wg nur Schlüssel und Peers verwaltet. Die MTU lebt auf der Netzwerkschnittstelle, deshalb liest du sie mit ip link show wg0.

Wenn du unsicher bist, welcher Fall gilt, lies zuerst die MTU und finde dann heraus, wer die Schnittstelle gestartet hat.

Entscheide danach, wer die Schnittstelle betreibt

Startet wg-quick sie, gewinnt eine ausdrückliche MTU-Zeile, andernfalls berechnet es einen Wert. Startet ein Netzwerkmanager sie, entscheidet das Profil dieses Managers. Startet eine Container-Laufzeit oder ein Anbieter-Client sie, lies deren Dokumentation, statt wg-quick-Verhalten anzunehmen.

Die Entscheidung ist nicht, welche Zahl abstrakt die beste ist. Sie ist, welche Komponente du tatsächlich konfigurieren kannst.

Was die Standardberechnung tut

wg-quick schlägt die Route zum Endpunkt des Peers nach, nimmt die MTU dieser ausgehenden Schnittstelle und zieht den Kapselungsaufwand ab. Mit einem äußeren IPv4-Kopf sind das etwa 60 Byte; mit IPv6 sind es etwa 80. Das Ergebnis wird gedeckelt, sodass ein Pfad von 1500 Byte 1420 ergibt statt eines Werts, der nur für eine Adressfamilie funktioniert. Das ist ein vernünftiger Standard, keine Messung deines Pfads.

Sie kann nichts über einen späteren Tunnel, eine Mobilfunkstrecke oder einen gefilterten ICMP-Pfad wissen.

Die Deckelung verbirgt eine echte Frage. Ist dein Pfad wirklich 9000 Byte von Ende zu Ende, lässt 1420 Leistung liegen, und ist der Pfad 1400, ist 1420 bereits zu groß. Der Standardwert ist ein Kompromiss, und so sollte er behandelt werden.

Wenn sich der Pfad unter dir ändert

Ein Laptop, der von Ethernet zu WLAN und dann zu einem Handy-Hotspot wandert, behält die MTU der Schnittstelle, mit der er gestartet ist. Der äußere Pfad ist jetzt vielleicht kleiner, und nichts verhandelt neu. Verschachtelte Tunnel machen es schlimmer, weil jede Schicht ihren eigenen Aufwand aus demselben Budget abzieht. Der Wert, der im Büro funktionierte, ist nicht der Wert, der am Flughafen funktioniert.

Ein kürzlicher Handshake beweist, dass die Schlüssel funktionieren. Er beweist nichts darüber, ob große Pakete hineinpassen.

Teste jeweils eine Zahl

Behalte dieselbe Anwendung und dasselbe Ziel, ändere einen Wert und miss. ping -M do -s 1372 testet ein Paket von 1400 Byte mit gesetztem DF-Bit, und das ist die Art Test, die du willst. Funktionieren kleine Anfragen und stocken große, hast du ein Größenproblem und kein Routingproblem.

Ändere nur die MTU. Mehrere Paketoptionen gleichzeitig anzupassen sagt dir nichts darüber, welche wichtig war.

Und erwarte nicht, dass eine MTU-Änderung eine fehlende Rückroute, eine Weiterleitungsregel oder einen DNS-Fehler behebt. Auch die erzeugen Symptome ohne Verkehr, und sie haben ihre eigenen Tests. Das wg-quick-Handbuch dokumentiert die automatische Auswahl.