Cisco ASA: Tunneled-Standardroute – wann sie wirklich greift

Ein Remote-Access-Benutzer erreicht nichts hinter der ASA, während derselbe Server Pings aus dem internen LAN beantwortet. Der Tunnel kommt hoch, der Client erhält eine Adresse aus dem Pool, und das Paket verlässt dennoch das Gerät über die Internet-Standardroute oder verschwindet. Dieses Muster bedeutet meist, dass der entschlüsselte Verkehr keine eigene Route gefunden hat und auf die gewöhnliche Standardroute durchgefallen ist. Die Lösung ist keine weitere NAT-Regel; sie ist die tunneled-Standardroute.

Beginnen Sie beim Symptom, nicht bei der Konfiguration

Beobachten Sie, wohin das Paket geht, statt wohin es Ihrer Erwartung nach gehen sollte. Ein Mitschnitt auf der Außenschnittstelle während einer fehlgeschlagenen Sitzung zeigt das entschlüsselte Paket auf dem Weg zum ISP-Gateway mit noch intakter Pool-Adresse, oder er zeigt gar nichts, weil die Suche fehlschlug. In beiden Fällen ist der Tunnel nicht das Problem.

Der Tunnel sieht in show vpn-sessiondb gesund aus, und genau deshalb debuggen Leute weiter IKE.

Was dies von einem ACL-Drop unterscheidet, ist die Richtung. Ein ACL-Drop wird protokolliert und gezählt, während eine fehlende Route einen fehlgeschlagenen Lookup ohne passenden Eintrag erzeugt. Führen Sie show route für das Ziel des Clients aus und lesen Sie, was die ASA tatsächlich gewählt hat, einschließlich der Frage, ob eine Standardroute gewählt wurde und welche.

Wie sich der tunneled-Lookup unterscheidet

Ciscos Leitfaden zum statischen Routing für ASA 9.23 dokumentiert eine separate Standardroute für entschlüsselten VPN-Verkehr, der keine statische oder gelernte Route hat. Das Schlüsselwort tunneled markiert diese Route, sodass ein entschlüsseltes Paket auf einen anderen Next Hop zurückfallen kann als den, den die ASA für ihren eigenen Transport verwendet. Spezifischere Routen gewinnen weiterhin, weshalb ein Client 10.0.0.0/8 über das interne Gateway erreichen und alles andere verlieren kann.

Ein minimales Layout hält zwei Standardrouten mit unterschiedlichen Next Hops. Eine trägt den eigenen Verkehr der ASA, die andere den entschlüsselten Verkehr ohne bessere Route. Beide Next Hops müssen weiterhin von der Schnittstelle aus erreichbar sein, an die Sie sie binden.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Wenn beide Standardrouten auf denselben Next Hop zeigen, ändert das Schlüsselwort nichts, und das Symptom bewegt sich nicht.

Die Einschränkungen, die entscheiden, ob es funktioniert

Derselbe Leitfaden erlaubt nur eine tunneled-Standardroute und stellt fest, dass ECMP dafür nicht unterstützt wird, sodass Sie diesen Pfad nicht per Lastverteilung nutzen können. Er listet außerdem Einschränkungen zu Route-Tracking, Reverse-Path-Prüfung und einigen Inspektions- und Management-Flows. Lesen Sie diese gegen Ihren installierten Release, bevor Sie um das Feature herum entwerfen. Ein Design, das sie ignoriert, scheitert meist an einer bestimmten Stelle statt überall, weshalb das Symptom intermittierend wirkt.

Die Reverse-Path-Prüfung ist die, die bei asymmetrischen Designs zubeißt. Käme die Antwort über eine andere Schnittstelle als von der ASA erwartet, wird das Paket verworfen, bevor Routing überhaupt zählt. Reparieren Sie die Topologie oder den Rückweg, statt die Prüfung abzuschalten, um einen Next Hop zu erzwingen.

Route-Tracking ist eine eigene Falle: Das getrackte Objekt schützt meist die gewöhnliche Standardroute, nicht die tunneled-Route.

Was das Schlüsselwort nicht tut

Es wählt nicht die Quelladresse, die die ASA zum Aufbau von IKE verwendet. Der äuöere Tunnelendpunkt folgt der eigenen Schnittstellen- und Quellwahl der Plattform, und die tunneled-Standardroute hat an dieser Entscheidung keinen Anteil. Sie zu ändern repariert keine phase 1, die von der falschen Adresse ausgeht.

Es macht den Next Hop auch nicht zu einem Proxy. Erwartet das Ziel einen HTTP-CONNECT-Austausch, liefern rohe IP-Pakete an einen Proxy-Host nur einen Host, der sie nicht routet. Konfigurieren Sie stattdessen den vom Client unterstützten Proxy-Mechanismus.

Und es erzeugt keine Weiterleitung flussabwärts. Das Gateway, auf das Sie zeigen, braucht weiterhin eine Route zurück zum VPN-Pool, plus Quellübersetzung, wo das Design sie vorsieht.

Prüfen Sie den Pfad von Ende zu Ende

Nachdem die Route steht, prüfen Sie vier Dinge der Reihe nach: show route für ein Ziel, das der Pool braucht, einen Mitschnitt auf der Schnittstelle zum neuen Next Hop, einen Mitschnitt auf dem Gateway selbst und einen Rückweg von diesem Gateway zur Pool-Adresse. Die ersten beiden belegen, dass die ASA den Pfad gewählt hat, die letzten beiden, dass jemand darauf antwortet.

Wenn das Gateway antwortet, der Client aber nie eine Antwort sieht, schauen Sie sich Quellübersetzung und Rückroute an, bevor Sie die Routingtabelle erneut anfassen.

Notieren Sie den Release, auf dem Sie validiert haben, denn die Einschränkungsliste ist versionsspezifisch, und ein Design, das auf einem Train funktioniert, kann auf einem anderen einen anderen Pfad brauchen. Diese Notiz überlebt den Konfigurationsschnipsel.