Site-to-Site-VPN funktioniert nur in eine Richtung: zwei verschiedene Fehler

Standort A erreicht B, B erreicht A nicht, und der Tunnel sieht in beide Richtungen in Ordnung aus. Bevor Sie den Tunnel anfassen, entscheiden Sie, welchen Fehler Sie wirklich haben. Eine an B neu aufgebaute Verbindung, die abgelehnt wird, und eine Antwort auf eine von A aufgebaute Verbindung, die nie ankommt, erzeugen ähnliche Beschwerden und völlig unterschiedliche Diagnosen. Das eine ist ein Richtlinien- oder Routenproblem auf dem Weg; das andere ein Rückweg- oder Zustandsproblem für Verkehr, der bereits erlaubt war.

Diese Unterscheidung entscheidet, welche Befehle sich lohnen.

Zwei Fehler, die identisch aussehen

Im ersten Fall sendet der Host von B ein SYN an A, und es kommt nichts zurück. Im zweiten öffnet der Host von A erfolgreich eine Sitzung, und die Antwort verschwindet auf dem Rückweg. Beide Anwender sagen, die Strecke sei einseitig, und beide beschreiben ein Paket, das verschwunden ist, also kann die Beschreibung allein sie nicht trennen.

Fragen Sie, welche Seite den fehlgeschlagenen Versuch begonnen hat. Diese eine Tatsache entfernt die Hälfte der möglichen Ursachen.

Prüfen Sie dann, dass der Test durchgehend dieselben Hosts und denselben Dienst verwendet hat. Ein Ping von einer Seite und eine Dateifreigabeverbindung von der anderen testen zwei verschiedene Dinge, und eine Diagnose vom Gateway aus kann eine Tunneladresse wählen, die kein Anwenderverkehr je nutzt.

Fall eins: Der Rückweg fehlt

Ein entfernter Server, der über ein anderes Standardgateway antwortet, kann die Anfrage empfangen und die Antwort woandershin routen. Zustandsbehaftete Firewalls verwerfen dann die asymmetrische Antwort, weil sie zu keinem aufgebauten Fluss passt, was genau wie eine Richtung aussieht, die nie funktioniert hat. Die Übersetzung fügt eine weitere Variante hinzu: Das Ziel sieht eine übersetzte Quelle und antwortet darauf, sodass eine Regel für die ursprüngliche Adresse nie passt.

Prüfen Sie die Adresse, die das Ziel nach der Übersetzung tatsächlich sieht, und den Rückweg für diese Adresse statt für das ursprüngliche Subnetz.

Fall zwei: Die Richtlinie hat es nie erlaubt

Der umgekehrte Fall ist einfacher und häufiger, als er aussieht: Ein Büro soll einen zentralen Dienst nutzen und nie Verbindungen ins Zentrum aufbauen. Diese Asymmetrie ist eine bewusste Zugriffsentscheidung, und der Tunnel arbeitet wie entworfen. Lesen Sie die Zugriffsrichtlinie, bevor Sie irgendeine Tunneleinstellung ändern. Das Dokument, nicht der Paketmitschnitt, sagt, welche Richtung gedacht war. Ein Mitschnitt kann nur zeigen, was passiert ist, nicht was erlaubt war.

Wenn beidseitige Initiierung wirklich nötig ist, fügen Sie die Berechtigung für den konkreten Dienst über den unterstützten Regelsatz der Plattform hinzu. Alle Subnetze gegenseitig zu vertrauen, um eine Anwendung zu reparieren, macht aus einer engen Anforderung eine breite Berechtigung, und dieser Tausch wird danach selten überprüft.

Vergleichen Sie vorher und nachher auf denselben Hosts

Beobachten Sie beide Enden desselben Versuchs, nicht zwei getrennte Versuche. Zeichnen Sie am Gateway des startenden Hosts und am Ziel auf und vergleichen Sie dann, was hereinkam, was hinausging und welche Adresse die Gegenseite sah.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Zeigt der Mitschnitt am Ziel die Anfrage mit einer unerwarteten Quelladresse, liegt die Antwort in Übersetzung oder Routing und nicht in der Sicherheitsrichtlinie des Tunnels. Zeigt das Ziel überhaupt keine Anfrage, hat das Paket den geschützten Weg nie überquert.

Wiederholen Sie nach einer Korrektur den identischen Test vom identischen Host und bestätigen Sie, dass unabhängiger Zugriff weiterhin verweigert wird. Ein Tunnelstatus von “established” stützt für sich genommen keine der beiden Schlussfolgerungen.