ASA-Hairpin: Internet-Ausgang oder Site-to-Site-VPN-Strecke?

Zwei Remote-Access-Nutzer hinter derselben ASA können Verkehr über dieselbe Outside-Schnittstelle senden und werden völlig unterschiedlich behandelt. Der eine geht zu einer öffentlichen Website, also braucht das Paket Quelltranslation und eine Internet-Route. Der andere geht zu einem Server hinter einem Site-to-Site-Tunnel, der ebenfalls auf dieser Schnittstelle endet, also braucht das Paket Identität, einen passenden Tunnel-Selektor und einen Rückweg zum Client-Pool. Die Same-Interface-Berechtigung ist für beide eine Voraussetzung und für keinen eine Lösung.

Zwei Strecken, eine Schnittstelle

Entscheiden Sie, welche Strecke Sie bauen, bevor Sie eine NAT-Regel tippen, denn die Regeln sind nicht austauschbar. Strecke A ist Client zu Internet: Pool-Adresse rein, übersetzte öffentliche Adresse raus, zurück durch dieselbe Schnittstelle. Strecke B ist Client zu einem privaten Präfix auf der Gegenseite eines anderen IPsec-Peers: Pool-Adresse bleibt erhalten, wird neu verschlüsselt und an einen Peer geliefert, der wissen muss, wie er den Pool beantwortet.

Was beide zuerst brauchen, ist die Same-Interface-Berechtigung. Ohne sie weigert sich die ASA, ein Paket über die Schnittstelle weiterzuleiten, auf der es angekommen ist, und der Fehler sieht wie ein Routing-Problem aus statt wie ein Policy-Problem:

same-security-traffic permit intra-interface

Diese eine Zeile erlaubt eine Weiterleitungsanordnung, wie die ASA-NAT-Referenz sie für Same-Interface-Pfade beschreibt. Sie fügt keine Client-Route hinzu, autorisiert keine Ressource, übersetzt keine Adresse und verhandelt keinen IPsec-Selektor; rechnen Sie also damit, danach noch drei oder vier Dinge zu ergänzen, und lesen Sie ihre Akzeptanz nicht als Fortschritt.

Strecke A: Der Client will ins Internet

Für einen Internet-Ausstieg muss die Pool-Adresse aufhören, privat zu sein, bevor das Paket das Gerät verlässt. In einem gewöhnlichen PAT-Design übersetzt die Regel den Pool in die Adresse der Outside-Schnittstelle, und der Rückweg-Zustand stellt den clientseitigen Flow wieder her:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Dann bestätigen Sie, dass der Client die ASA tatsächlich gebeten hat, diesen Verkehr zu tragen. Ein Split-Tunnel-Ausschluss schickt das öffentliche Ziel über die eigene Verbindung des Telefons, die die ASA nie erreicht, und keine NAT-Regel repariert ein Paket, das nie gesendet wurde. Prüfen Sie die Split-Tunnel-Liste der Gruppenrichtlinie gegen das Ziel, das Sie testen.

Der Rest der Strecke ist gewöhnlich: eine nutzbare Default- oder spezifische Route aus der Outside-Schnittstelle, eine Zugriffsrichtlinie, die den Flow erlaubt, und DNS gemäß der Resolver-Richtlinie, die Sie gewählt haben. Fügen Sie route-lookup hier aus demselben Grund wie unten hinzu, da Eintritts- und Austrittsschnittstelle identisch sind.

Strecke B: Der Client will eine private Site

Diese Strecke scheitert an mehr Stellen, also schreiben Sie sie der Reihe nach. Zuerst die Client-Route: Das Zielpräfix muss in der Split-Tunnel-Liste stehen, sonst legt der Client es nicht in den Tunnel. Zweitens der Tunnel-Selektor: Die Crypto-ACL des Site-to-Site muss Pool-Adresse zum Remote-Präfix abdecken, nicht nur das lokale LAN zum Remote-Präfix. Drittens Identität, damit die Pool-Adresse unterwegs nicht in das Internet-PAT übersetzt wird.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Die Gegenseite ist der Teil, den man zu testen vergisst. Der Peer braucht eine Route zurück zum Pool und einen Selektor, der ihn einschließt, und seine eigene Richtlinie muss die Quelladressen erlauben, die er sehen wird. Wird die Site stattdessen über eine übersetzte Sicht genutzt, ist das ein gültiges Design, aber dann müssen beide Peers, beide Selektoren und beide Routing-Tabellen sich über die übersetzten Adressen einig sein.

Prüfen Sie auch die Regelreihenfolge. Eine breite PAT-Regel über der Identitätsregel übersetzt den privaten Austausch, bevor die Identitätsregel überhaupt ausgewertet wird, und das Symptom ist ein Site-Tunnel ohne passende SA statt eines NAT-Fehlers.

Der Test, der Ihnen sagt, welche Strecke Sie gebaut haben

Nutzen Sie die Pfadauswertung der ASA selbst, statt die Konfiguration zu lesen und zu hoffen. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed zeigt die NAT-Entscheidung, die Route und das ACL-Ergebnis für einen Flow; wiederholen Sie es mit einem privaten Ziel. Wenn die NAT-Phase einen privat-zu-privat-Flow umschreibt, haben Sie Strecke A für ein Paket gebaut, das Strecke B brauchte.

Zwei weitere Befehle schließen die Lücke. show nat detail druckt die Regelreihenfolge, der packet-tracer gefolgt ist, und show crypto ipsec sa zeigt, ob ein Selektor für das erwartete Paar existiert. Eine fehlende SA ist ein Selektor- oder Peer-Konfigurationsproblem, nichts, was die NAT-Regel reparieren kann.

Prüfen Sie jede Strecke mit dem Verkehr, den sie bedient

Akzeptieren Sie Strecke A mit einer gewöhnlichen öffentlichen Anfrage des Clients und Strecke B mit einer Anfrage an eine private Ressource, die tatsächlich existiert. Wiederholen Sie dann jede mit einer verweigerten Ressource, denn „erlaubt“ und „von der Zugriffsrichtlinie gestattet“ sind nicht derselbe Beweis, und ein vom Hub ausgehender Ping testet keinen der beiden Client-Pfade.

Halten Sie die beiden Testaufzeichnungen im Ticket getrennt: Quelladresse, Ziel, passende NAT-Regel und Ergebnis. Wenn der nächste Bericht sagt „das VPN ist kaputt“, sagt Ihnen das Paar innerhalb einer Minute, welche Strecke zurückgefallen ist, und die Antwort ist meistens eine Route oder ein Selektor statt der Same-Interface-Zeile, die alle zuerst verdächtigen.