ASA Identity NAT versus IOS NAT-Ausnahme für VPN-Verkehr

Auf Cisco-Gateways behalten sowohl ASA Identity NAT als auch eine IOS-Ausnahme im NAT-Klassifikator die VPN-Adressen bei. Die Regeln unterscheiden sich darin, wo die Übersetzung übersprungen wird.

Eine Filiale betreibt Internet-PAT und ein Site-to-Site-VPN auf demselben Cisco-Gateway, und das VPN funktioniert nicht mehr, sobald NAT hinzukommt. Die Adressen im Tunnel passen nicht mehr zu dem, was die Crypto-ACL schützt, oder der Peer sieht übersetzte Adressen, für die er keine Route hat. Cisco löst das an zwei Stellen: Die ASA wählt eine NAT-Regel, die eine Adresse auf sich selbst abbildet, während IOS den Flow über ein Deny in der ACL aus einer Übersetzungsregel heraushält. Beide erhalten die ursprünglichen Adressen, und keines ist eine Umgehung der NAT-Verarbeitung.

Den Flow aufzeichnen, bevor eine Regel gewählt wird

Schreiben Sie zuerst den Flow auf, den Sie schützen wollen: LAN-Quelle, entferntes Ziel und das genaue Adresspaar, das die IPsec-Richtlinie schützt. Tun Sie das, bevor Sie eine Regel bearbeiten, denn das Tupel zeigt, welcher Klassifikator oder welche NAT-Regel hätte passen müssen.

Suchen Sie dann die Regel, die tatsächlich gepasst hat, nicht die, die passen sollte. Auf beiden Plattformen wird NAT in einer Reihenfolge ausgewertet, und eine frühere Regel kann gewinnen, bevor Ihre Ausnahme überhaupt betrachtet wird. Eine scheinbar korrekte Ausnahme, die gegen eine andere Regel verliert, liefert der Schutzrichtlinie nie das erwartete Paket. Das Symptom gleicht einer fehlenden Ausnahme, deshalb muss die Regelreihenfolge vor der Konfigurationsänderung gelesen werden.

ASA Identity NAT ist eine Regel, keine Umgehung

Auf der ASA ist Identity NAT eine NAT-Regel, deren übersetzte Adresse der ursprünglichen entspricht. Sie wird wie jede andere Regel ausgewählt und legt weiterhin einen Übersetzungseintrag an, das Paket überspringt die NAT-Verarbeitung also nicht. Geändert wird nur, dass die Adressen auf dem Draht gleich bleiben, und genau das braucht die IPsec-Richtlinie.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Die Schnittstellen der Regel und ihre Route-Lookup-Einstellung müssen zum Weiterleitungsdesign passen. Eine Regel, die die Adresse korrekt abbildet, aber auf das falsche Schnittstellenpaar angewendet wird, wird für Ihren Flow nicht ausgewählt. Route-Lookup entscheidet, ob das übersetzte Paket geroutet wird oder das ursprüngliche Ziel verwendet wird, und das entscheidet, ob Rückverkehr durch den Tunnel zurückkommt.

Der Verwaltungszugriff auf die ASA selbst ist ein eigener Fall. Wenn Sie Identity NAT für Verwaltungsverkehr verwenden, gilt die releaseabhängige Route-Lookup-Anforderung, und eine breite, aus einem VPN-Beispiel kopierte Ausnahme repariert SSH nicht.

Ein Deny in der IOS-NAT-ACL heißt hier nicht ausgewählt

Auf IOS wird Internet-NAT über eine Quellliste gesteuert, und diese ACL ist ein Klassifikator, kein Filter. Eine Permit-Zeile wählt Verkehr für die Übersetzung aus; eine Deny-Zeile bedeutet, dass das Paket hier nicht ausgewählt wird. Dieses Deny ist keine Anweisung, das Paket zu verwerfen, wie es ein Deny in einer Schnittstellen-ACL wäre.

Hier nicht ausgewählt ist zudem enger als nirgends übersetzt. Eine andere NAT-Regel, eine andere Schnittstelle oder eine Route-Map können den Flow weiterhin übersetzen, daher muss die gesamte NAT-Tabelle gelesen werden. Das Paket braucht außerdem weiterhin eine Route, eine passende Crypto-ACL und Erlaubnis an den tatsächlichen Zugriffskontrollgrenzen.

Eine minimale IOS-Anordnung setzt das Deny über das Permit in derselben Liste und richtet die Overload-Regel auf diese Liste. Die Crypto-ACL schützt dann dasselbe Paar, das das Deny von der Übersetzung ausnimmt.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Eine prüfbare Frage für beide Modelle

Beide Modelle beantworten dieselbe Frage: Welche Regel hat diesen Flow getroffen, und welche Adressen haben die Schnittstelle verlassen? Zeichnen Sie an der Außenschnittstelle auf und vergleichen Sie die Quelladresse vor und nach dem Gateway. Prüfen Sie dann die Sicht des Peers auf den Tunnel, denn die SA kann stehen, während der geschützte Flow anderswo übersetzt wird.

Auf der ASA zeigen Sie nat detail und die Übersetzungstabelle; auf IOS zeigen Sie ip nat translations und die passenden ACL-Zähler. Eine Regel, die nie hochzählt, wurde nie ausgewählt, und das deutet auf Reihenfolge, Schnittstelle oder Richtung hin, nicht auf die Crypto-Konfiguration.

Wo die Konfiguration meist schiefgeht

Die häufigen Fehler sind mechanisch. Das Deny steht unter dem Permit und passt nie. Der Klassifikator wird in die falsche Richtung angewendet, sodass der Rückfluss übersetzt wird. Die Identity-Regel deckt die richtigen Adressen ab, aber das falsche Schnittstellenpaar. Die Crypto-ACL schützt ein Subnetz, das nicht mehr zu dem passt, was die NAT-Regel anbietet.

Notieren Sie das ursprüngliche und das angebotene Adresspaar neben dem Regelverantwortlichen, damit der nächste Engineer sieht, warum ein Klassifikator die Übersetzung verweigert, während die Firewall die Anwendung erlaubt. Bewahren Sie das im Change-Ticket auf, nicht in einer persönlichen Notiz. Führen Sie den Flow nach jeder NAT-Änderung erneut aus, denn die Regelreihenfolge ist Teil der Konfiguration, auch wenn der Regeltext unverändert bleibt. Ein Tunnel, der hochkommt, ist kein Beweis, dass die Adressen überlebt haben; nur das mitgeschnittene Paket und die entschachtelte Sicht des Peers sind es.

Ähnliche Artikel