WireGuard stockt: eine MTU-Grenze oder eine fehlende Weiterleitungsregel?
Nichts jenseits des Servers ist ein Weiterleitungs- oder Rückrouteproblem. Kleine Anfragen, die laufen, während große stocken, sind die Signatur der Paketgröße.
Die Gewohnheit ist, die MTU zu senken, sobald sich WireGuard falsch verhält, und diese Gewohnheit verbirgt einen anderen Fehler. Ein Gateway, das nicht weiterleitet, und ein Pfad, der keine großen Pakete trägt, erzeugen unterscheidbare Muster: das eine versagt in beide Richtungen und bei jeder Größe, der andere überlebt kleine Anfragen und stirbt bei großen. Bestimmen Sie, welche Form Sie haben, bevor Sie irgendeine Zahl ändern. Der Test ist billig, und er beseitigt die Hälfte der möglichen Ursachen.
Zwei Fehler, zwei verschiedene Formen
Ein Weiterleitungsproblem zeigt sich unmittelbar hinter dem Server. Der Handshake gelingt, die Tunneladresse antwortet, und nichts hinter dem Gateway ist erreichbar, nicht einmal mit einer winzigen Anfrage. Das Paket erreichte den Server und wurde nicht weitergegeben, oder die Antwort hatte keine Route zurück.
Ein Größenproblem zeigt sich erst oberhalb einer Schwelle. DNS, ein TCP-Handshake und ein kleiner API-Aufruf funktionieren, während ein Dateidownload oder eine große Antwort hängen bleibt. Die Pakete, die passten, reisten von Ende zu Ende, und die, die nicht passten, wurden irgendwo ohne brauchbaren Bericht verworfen.
Diese Beschreibungen deuten auf verschiedene Menschen und verschiedene Konfigurationsdateien hin, deshalb ist es mehr wert, die Form zu messen, als zu raten. Ein einzelner Ping zum Gateway kann sie nicht trennen.
Schließen Sie Weiterleitung aus, bevor Sie irgendetwas verkleinern
Testen Sie ein Ziel jenseits des Gateways, nicht das Gateway selbst. Ein Ping an die Tunneladresse des Servers beweist nur, dass die Schnittstelle aktiv ist und dass Sie die Maschine erreichen, die den Tunnel beendet. Verkehr für das weitere Netz hängt davon ab, dass auf dieser Maschine IP-Weiterleitung aktiviert ist, und von einer Firewall, die den weitergeleiteten Fluss zulässt. Beides muss zutreffen, und ist eines davon falsch, entsteht dieselbe Stille.
Auch die Rückroute zählt. Weiß das Zielnetz nicht, wie es die Tunneladresse des Clients erreicht, kommt die Anfrage an, und die Antwort verschwindet, und der Client meldet eine Zeitüberschreitung, die einer verworfenen Weiterleitung gleicht.
Wo das Design Adressübersetzung verwendet, ist die Übersetzungsregel Teil dieses Rückwegs. Sie zu entfernen, während man einem MTU-Problem nachgeht, macht aus einem funktionierenden Design ein kaputtes, deshalb lesen Sie die bestehenden Regeln, bevor Sie sie bearbeiten.
Messen Sie, wo der Bruch beginnt
Lesen Sie zuerst den Weiterleitungszustand und die Filterregeln. Das sind reine Leseprüfungen, und sie beantworten die billige Frage:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Prüfen Sie dann Größen mit dem Don’t-Fragment-Bit, vom Client aus, in Richtung eines Hosts jenseits des Gateways:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Funktioniert die erste Prüfung und scheitert die zweite mit einem Fragmentierungsfehler, teilt der Pfad Ihnen seine nutzbare Größe mit. Funktioniert keine von beiden, sehen Sie auf Weiterleitung oder Routing, und die MTU ist nicht die Variable, die zu ändern ist.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Reparieren Sie die Schicht, die Sie bewiesen haben
Ist die Weiterleitung der Fehler, ist die Korrektur eine Weiterleitungsregel oder eine Route, so eng formuliert, wie das Design es zulässt. Ist die Größe der Fehler, ist die Korrektur eine MTU, die die Kapselung auf genau diesem Pfad berücksichtigt, angewendet auf die Schnittstelle, die sie braucht, und nicht auf jeden Adapter der Flotte.
So oder so, wiederholen Sie danach dieselbe Aufgabe gegen dasselbe Ziel. Läuft die ursprüngliche große Übertragung jetzt durch, hat die Änderung die Schicht adressiert, die versagte. Hat sich nur die kleine Prüfung verbessert, haben Sie ein Symptom behandelt, und die echte Grenze steht noch.
Notieren Sie, welche Form Sie vor der Änderung beobachtet haben. Diese eine Zeile, neben der Korrektur festgehalten, ist es, was den Nächsten davon abhält, eine MTU zu senken, die nie das Problem war.