Warum Routen mit gleichen Kosten VPN-Fehler schwer sichtbar machen
Wenn sich mehrere Tunnel dieselben Kosten teilen, kann jeder Fluss einen anderen nehmen. Ein erfolgreicher Ping sagt nichts über den Pfad aus, den Ihre Anwendung tatsächlich nutzt.
Ein Nutzer meldet, dass die interne Anwendung von einem Rechner aus funktioniert und von einem anderen aus scheitert, während der Ping vom Gateway in beiden Fällen gelingt. Bei mehreren Tunneln mit gleichen Kosten ist das kein Widerspruch. Jeder Fluss wird auf einen eigenen nächsten Hop gelegt, sodass Ihre Prüfung und die Sitzung des Nutzers einfach verschiedene Pfade nutzen können. Die folgende Untersuchung reproduziert diese Wahl, bevor irgendetwas geändert wird.
Ein Ping, mehrere mögliche Pfade
Hat eine Route mehr als einen nächsten Hop mit gleichen Kosten, muss der Router pro Paket einen auswählen. Die meisten Implementierungen hashen Felder aus dem Paket, typischerweise Quell- und Zieladresse zusammen mit Protokoll und Ports, damit Antworten auf demselben Pfad bleiben. Verschiedene Anwendungen, ja sogar verschiedene Verbindungen einer Anwendung, erzeugen verschiedene Hashes.
Deshalb beweist eine Diagnose vom Gateway so wenig. Die eigene Prüfung des Gateways hat eigene Adressen und Ports und damit einen eigenen Hash. Sie kann auf dem gesunden Tunnel landen, während der Nutzer weiter auf dem defekten landet.
Wie die Plattform einen nächsten Hop wählt
Reproduzieren Sie die Wahl, statt sie zu raten. Fragen Sie den Kernel, welche Route er für dieselbe Quelle und dasselbe Ziel wie die fehlschlagende Sitzung verwenden würde. Diese Abfrage umfasst Felder, die eine reine Zielabfrage ignoriert. Führen Sie sie auch von einem funktionierenden Client aus und vergleichen Sie die beiden Antworten:
ip route get 10.20.5.7 from 10.20.0.14Neuere iproute2-Versionen akzeptieren auch Protokoll und Zielport, was zählt, wenn der Hash sie enthält. Vergleichen Sie diese Ausgabe mit derselben Abfrage von einem funktionierenden Client, und der Unterschied ist der Beweis, der Ihnen fehlte.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Folgen Sie dem fehlerhaften Fluss, nicht der Routentabelle
Die Routentabelle listet beide Tunnel und sieht per Definition korrekt aus. Die Frage ist, was jeder Tunnel mit dem Paket tut, nachdem es ausgewählt wurde. Prüfen Sie, dass beide dieselben geschützten Präfixe, dieselbe Weiterleitungserlaubnis und einen Rückweg tragen, der denselben Client erreicht.
Achten Sie auf zustandsbehaftete Geräte in der Mitte. Wenn eine Anfrage über den einen Tunnel hinausgeht und die Antwort über den anderen zurückkommt, wird eine Firewall oder ein NAT, die den ursprünglichen Fluss nie gesehen haben, sie verwerfen. Beide Tunnel leiten Verkehr korrekt weiter, und die Verbindung scheitert trotzdem.
Prüfen Sie außerdem die MTU pro Pfad. Ein Pfad mit zusätzlicher Kapselung verkleinert die nutzbare Größe, und eine Übertragung, die über den einen Tunnel gelingt, stockt auf dem anderen genau bei der Größe, bei der der kleinere bricht.
Vergleichen Sie einen Pfad nach dem anderen
Wo das Design Wartung erlaubt, nehmen Sie einen Tunnel außer Betrieb und wiederholen Sie die Aufgabe des Nutzers. Verschwindet der Fehler, gehört das Problem zu dem entfernten Pfad, und der nächste Schritt ist, seine Konfiguration mit der des Nachbarn zu vergleichen, statt die Routing-Tabelle erneut zu prüfen.
Vergleichen Sie die echte Anwendung, nicht wiederholte Pings. Halten Sie fest, ob der Fehler einem bestimmten nächsten Hop, einer Paketgröße oder einem Übergang nach dem Wiederverbinden folgt, denn diese drei Muster deuten auf unterschiedliche Reparaturen hin.
Schreiben Sie schließlich auf, warum die Pfade als gleichwertig gelten und wie ein Fehler einen davon außer Betrieb nehmen soll. Multipath ist nur sicher, wenn die Pfade wirklich austauschbar sind, und das ist eine Designaussage, die man prüfen und nicht annehmen sollte.