Welche Schnittstelle bekommt die NAT-Inside- und NAT-Outside-Rolle an einem IOS-VPN-Ausgang

Router, die einen Internet-Ausgang mit vollem Tunnel bereitstellen, erledigen zwei Aufgaben, die wie eine aussehen. Sie beenden den Tunnel und leiten das entschlüsselte Client-Paket ins Internet weiter. Nur die zweite Aufgabe braucht Übersetzung, und die Übersetzung muss zum inneren Fluss passen. Diese Unterscheidung entscheidet, welche Schnittstellen die NAT-Rollen tragen und welcher Adressbereich in der Regel erscheint.

Verfolgen Sie ein Paket durch den Router

Nehmen Sie einen Client an 10.90.0.25, der einen öffentlichen HTTPS-Dienst öffnet. Ob dieses Ziel überhaupt in den Tunnel gelangt, entscheidet die Richtlinie des Clients selbst. Sobald es geschieht, entschlüsselt der Router das Paket und übergibt es an eine virtuelle Schnittstelle, von wo es zum öffentlichen Uplink geroutet wird.

Diese virtuelle Schnittstelle ist die Innenseite der Übersetzung. Der öffentliche Uplink ist die Außenseite. Sind die Rollen vertauscht oder fehlen sie, verlässt das Paket entweder mit einer privaten Quelle oder wird verworfen, bevor es übersetzt wird.

Passen Sie die Übersetzungsrichtlinie an den Client-Pool an

Die NAT-Regel muss den Bereich nennen, den die Clients tatsächlich erhalten, nicht das Büro-LAN, das zufällig denselben Uplink teilt. Eine Regel, die nur das lokale Subnetz abdeckt, verfehlt entfernte Clients, selbst wenn beide über dieselbe Schnittstelle gehen.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Halten Sie Ausnahmen für private Standorte getrennt. Verkehr zu internen Zielen muss seine ursprüngliche Quelle behalten, sonst antwortet das Ziel an eine Adresse, die es nicht erreichen kann, und der Rückweg scheitert auf eine Weise, die wie eine Routingschleife aussieht.

Wenden Sie die Rollen auf die tatsächlichen Schnittstellen im ausgerollten Design an. Ein aus einer alten Easy VPN-Antwort kopiertes Virtual-Template-Fragment ist keine vollständige aktuelle Konfiguration, und der verwendete Tunneltyp bestimmt, welche Schnittstelle das entschlüsselte Paket erhält.

Halten Sie äußeren Transport und innere Übersetzung getrennt

Eine entschlüsselte Anwendungsquelle zu übersetzen ist nicht derselbe Vorgang, wie IKE- oder geschützte Pakete durch ein NAT-Gerät weiter oben zu schieben. Das Erste ändert, was das Internet als Quelle der Client-Anfrage sieht; das Zweite hält einen Tunnel über eine Zwischenbox hinweg am Leben.

Verwechselt man beides, entstehen zwei klassische Fehler. Ein Router, der seinen eigenen Tunneltransport übersetzt, bricht die Peer-Beziehung, während ein Router, der den inneren Fluss nie übersetzt, private Adressen ins Internet weiterleitet. Lesen Sie, welchen Fluss Sie vor sich haben, bevor Sie eine Regel bearbeiten, und prüfen Sie, ob der Tunnel nach der Änderung oben blieb. Eine Regel, die das Browsen repariert, aber den Tunnel fallen lässt, hat das Problem verschoben statt gelöst.

Keiner der beiden Fehler wird durch Ändern des anderen behoben. Lesen Sie, welchen Fluss Sie vor sich haben, bevor Sie eine Regel bearbeiten.

Prüfen Sie an beiden Grenzen

Lesen Sie die Anwendungsquelle an der Internetgrenze und das wiederhergestellte Ziel auf dem Rückweg. Das Erste sagt, ob die Übersetzung stattfand; das Zweite sagt, ob die Rückabbildung beim richtigen Client ankam.

Testen Sie dann einen Client, der einen genehmigten Split-Tunnel-Pfad nutzt. Dieser Client nutzt nie die Internet-Übersetzung dieses Routers, verhält sich also anders, und der Unterschied bestätigt, welchen Pfad der Verkehr genommen hat.

Verhalten sich beide Clients gleich, tut die Split-Tunnel-Richtlinie nicht, was das Design sagt. Beheben Sie das, bevor Sie weitere Übersetzungsregeln hinzufügen, denn eine Regel für einen ungenutzten Pfad verbirgt das eigentliche Problem.