Warum ein funktionierendes VPN beim Antwortpaket trotzdem in einen Timeout läuft
Dass eine Anfrage einen privaten Server erreicht, ist nur die Hälfte des Austauschs. Ihre Antwort muss den Tunnelclient über das vorgesehene Gateway, die Route oder die Übersetzung finden.
Die Anfrage kommt an, der Server protokolliert sie, und der Client meldet weiterhin einen Timeout. Diese Kombination bedeutet, dass die Antwort den Rückweg nicht gefunden hat, und das ist einer der wenigen Fehler, die du von beiden Enden gleichzeitig bestätigen kannst. Arbeite die Prüfungen der Reihe nach ab und halte an, sobald eine davon fehlschlägt.
Beginne damit, wo die Anfrage angekommen ist
Bestätige, dass das Paket den Dienst erreicht hat, bevor du irgendetwas anderes untersuchst. Ein Logeintrag auf Serverseite, ein Verbindungszähler oder ein erlaubter Mitschnitt am fernen Ende beantworten alle dieselbe Frage, und ihr Fehlen schickt dich zurück zum Tunnel statt vorwärts zur Antwort. Das ist die Prüfung, die ein Weiterleitungsproblem von einem Rückwegproblem trennt.
Wenn die Anfrage nie angekommen ist, höre hier auf. Tunnel, Routing zum privaten Präfix oder die Zugriffsregel sind das Thema, und der Rückweg ist noch nicht relevant. Notiere auch die Quelladresse, die der Server gesehen hat. Sie ist entweder die Pooladresse, die der Client erhalten hat, oder eine übersetzte Adresse, und dieser Unterschied entscheidet, welche der späteren Prüfungen greift.
Die Antwort braucht eine Route zum Pool
Ein Fernzugriffsclient erhält normalerweise eine Adresse aus einem Pool, und das private Netz braucht eine Route zurück zu diesem Pool. Ein Server, dessen Standardroute auf sein eigenes Gateway zeigt, übergibt das Paket an dieses Gateway, das keine Ahnung hat, wo der Pool liegt, und dort stirbt die Antwort. Der Client sieht einen Timeout, weil nichts zurückkam, was sich nicht von einer Anfrage unterscheiden lässt, die nie hinausging.
Prüfe die Route, die der Server für die Clientadresse wählt, und nicht die Route, die er für sein eigenes Subnetz verwendet. Diese beiden Suchen können unterschiedliche Antworten liefern, und die zweite ist hier die entscheidende. Übersetzung ist der alternative Entwurf, und sie ändert, was der Server sieht. Sie kann einen Rückweg vereinfachen, und sie entfernt außerdem die ursprüngliche Clientadresse aus den Serverlogs, was jede Regel oder jeden Bericht betrifft, der auf diesem Feld aufbaut.
Vergleiche den Mitschnitt auf dem Server mit dem Mitschnitt am Gateway
Vergleiche, was den Server verlässt, mit dem, was am Gateway ankommt. Ein Mitschnitt an der ausgehenden Schnittstelle des Servers und ein Mitschnitt am Tunnelgateway beantworten unterschiedliche Hälften der Frage, und die Lücke dazwischen lokalisiert den Verlust.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Eine vom Gateway selbst erzeugte Anfrage ist ein schlechter Ersatz für einen Clienttest, weil sie von einer anderen Adresse stammt und auf andere Regeln trifft. Deshalb können ein erfolgreicher Ping vom Gateway und eine fehlschlagende Anfrage vom Client gleichzeitig zutreffen.
Wenn mehrere Router auf dem Pfad liegen, prüfe jeden, der eine Route zum Pool braucht. Ein Standort-zu-Standort-Entwurf verlangt oft, dass das entfernte Präfix auf mehr als einem Gerät bekannt ist, und das Gateway selbst muss zwischen Tunnel und LAN weiterleiten; die strongSwan-Hinweise zur Weiterleitung decken die sysctl- und Firewall-Seite davon ab.
Halte Pool, Präfix und Verantwortlichen fest
Vier Fakten gehören in die Notiz: der Pool, den der Client erhalten hat, das private Präfix, das er brauchte, der Router, der für die Antwort verantwortlich ist, und die Übersetzungsregel, falls es eine gibt. Damit ist eine spätere Gateway-Änderung ein Vergleich und keine Untersuchung.
Teste danach erneut mit einem gewöhnlichen Client und dem echten Anwendungskonto. Das Ausweiten von Anwendungsrechten kann den Rückweg eines Pakets nicht reparieren, und eine Kontenänderung während dieser Diagnose verwirrt den nächsten Vergleich. Wenn der Entwurf auf Übersetzung setzt, dokumentiere sie dort, wo die Serverlogs gelesen werden. Wer in einer Prüfspur eine unbekannte Quelladresse sieht, sollte die Zuordnung nicht aus einem Ticket neu herausfinden müssen.