VPN-Standort-Erweiterung: Folgen Sie der Rückroute hinter dem Gateway

Der Datenverkehr einer Filiale endet an einem Gateway, dessen LAN die Anwendung nicht enthält, die Sie erreichen sollten. Der Server steht in einem zweiten Rechenzentrum, hinter einer internen Verbindung, die das VPN nie konfiguriert hat. Ein weiteres Präfix am nahen Gateway hinzuzufügen, bewirkt für diesen Fall nichts, weil das ferne Gateway ein Verschlüsselungsendpunkt und nicht der letzte Router ist. Der Pfad braucht eine Weiterleitung, eine Zulassung an der fernen Sicherheitsgrenze und eine Rückentscheidung im eigenen Netz der Destination.

Das ferne Gateway ist ein Verschlüsselungsendpunkt

IPsec zwischen Gateways schützt den Verkehr zwischen zwei Sicherheitsgeräten, und die inneren Adressen reisen verschlüsselt über diesen Abschnitt. Jenseits des fernen Gateways übernimmt das gewöhnliche Routing, einschließlich jeder Richtlinie, die zwischen Rechenzentren besteht. Der geschützte Abschnitt deckt also einen Teil der Strecke ab und nicht den Rest. Das Gegenteil anzunehmen führt dazu, dass ein Entwurf mit einem gesunden Tunnel und einer unerreichbaren Anwendung endet.

Zeichnen Sie den Pfad in drei Teilen: Filiale zum nahen Gateway, nahes zum fernen Gateway, fernes Gateway zur Anwendung. Jeder Teil hat seinen eigenen Verantwortlichen und seinen eigenen Fehlermodus.

Lesen Sie beide Richtungen der Tunnelrichtlinie

Eine Tunnelrichtlinie wird üblicherweise aus Sicht der lokalen Seite geschrieben, und genau aus dieser Gewohnheit entstehen Teilkonfigurationen. Beide Peers müssen die Filialquelle und das Ziel so auflisten, wie sie im Tunnel erscheinen werden, einschließlich jeder Übersetzung, die der Entwurf vorsieht. Nur das nahe Ende zu aktualisieren erzeugt eine Phase-zwei-Abweichung, die wie ein Routingfehler aussieht. Vergleichen Sie beide Richtliniensätze, bevor Sie eine Route anfassen.

Schreiben Sie Quelle und Ziel als Adressen statt als Standortnamen. Unklarheit hier taucht später als rätselhafte Asymmetrie wieder auf.

Fügen Sie die Weiterleitung hinzu und bestätigen Sie die Zulassung

Das ferne Gateway braucht eine Route zum Anwendungssubnetz, und jeder Router dazwischen muss die Filialquelle zulassen. Prüfen Sie, was das ferne Gateway tatsächlich hat, statt was das Diagramm behauptet.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Der erste Befehl meldet die Ausgangsschnittstelle und den nächsten Hop, den das ferne Gateway für diese Quelle wählen würde, eine Frage, die eine gewöhnliche Routing-Tabelle nicht beantworten kann. Die Ablaufverfolgung zeigt, wo Pakete stoppen, und ein Abbruch hinter dem fernen Gateway deutet auf internen Transit hin und nicht auf den Tunnel. Wenn die Route existiert und der Verkehr trotzdem verschwindet, zeichnen Sie am fernen Gateway auf und lesen Sie die ankommende Quelladresse, denn eine unerwartete Adresse bedeutet, dass irgendwo ungeplant übersetzt wird. Alle Adressen hier sind Platzhalter, also setzen Sie die echten Subnetze für Filiale, Transit und Anwendung ein.

Testen Sie aus der Filiale und testen Sie dann den alten Pfad erneut

Die Abnahme braucht eine echte Quelle statt einer Sonde vom fernen Gateway. Führen Sie die Prüfung von einem Host in der Filiale aus und behalten Sie die zuvor funktionierenden Ziele im selben Test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Eine Antwort der Anwendung beweist den Hinweg und den Rückweg zusammen, während der Ping zum alten Ziel beweist, dass die Änderung nicht kaputt gemacht hat, was bereits funktionierte. Erfassen Sie die Quelladresse, die die Anwendung protokolliert, denn ihre Zugriffsregeln und jede Rückroute müssen zu diesem Wert passen. Wo die Filiale vor dem Tunnel übersetzt, unterscheiden sich die Richtlinienadresse und die Adresse, die die Anwendung sieht, planmäßig, also halten Sie beide fest. Wiederholen Sie den Test nach einer Schlüsselerneuerung oder einer Routingänderung, denn diese Pfade werden gern einmal validiert und dann vergessen.

Weisen Sie jedem der drei Abschnitte und der Rückroute im Zielnetz einen Verantwortlichen zu. Ein Pfad mit vier Verantwortlichen versagt in den Lücken dazwischen.