ASA VPN-Hairpin: zwei Tunnel über eine Schnittstelle routen

Der Verkehr eines Remote-Benutzers kann dieselbe ASA-Schnittstelle verlassen, über die er angekommen ist, aber Hairpin-Erlaubnis, Tunnelumfang, NAT und ACLs sind vier getrennte Entscheidungen.

Ein Remote-Benutzer verbindet sich mit der ASA, fragt nach einem Host hinter einer Filiale, und die ASA schickt diese Anfrage über genau die Schnittstelle hinaus, über die der Benutzer hereinkam. Nichts daran erfordert einen zweiten physischen Port. Was es erfordert, sind vier unabhängige Entscheidungen, die Menschen gern zu einer zusammenfassen: die Erlaubnis zum Hairpin, einen Tunnel, der die richtigen Adressen schützt, eine NAT-Richtlinie, die die zugesagte Quelle bewahrt, und eine Zugriffsrichtlinie, die den Dienst autorisiert.

Ein Paket, zwei Tunnel

Folgt man dem Ablauf, verliert die Reihenfolge der Vorgänge ihr Geheimnis. Das Paket kommt im Remote-Access-Tunnel an, wird entschlüsselt und zu einem gewöhnlichen IP-Paket mit einer Quelle aus dem Client-Pool. Die ASA routet es dann, gleicht es gegen die Crypto-ACL von Standort zu Standort ab, verschlüsselt es erneut und sendet es über die Außenschnittstelle in Richtung Filiale.

Die folgenden Adressen sind illustrativ, aber die Form zählt: Die Quelle ist der Pool, nicht das interne LAN der ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Daraus folgen zwei Dinge. Der Client braucht eine Route für das Filialpräfix über seine Remote-Access-Verbindung, was bedeutet, dass der Split-Tunnel oder die zugeschobene Routenliste sie enthalten muss. Und die Filiale muss wissen, wie sie Verkehr an 10.77.0.20 oder an die Adresse zurückgibt, die Ihr NAT-Design eingesetzt hat.

Hairpin-Erlaubnis ist global

Der Befehl, zu dem man greift, ist same-security-traffic permit intra-interface. Er erlaubt Verkehr, dieselbe Schnittstelle zu betreten und zu verlassen, was genau das ist, was dieser Pfad braucht. Er ist außerdem eine globale Einstellung: Wird er aktiviert, ändert sich das Verhalten anderer Flüsse, die zufällig dieselbe Schnittstelle zweimal durchlaufen.

Deshalb gehört er in einen Änderungsdatensatz und nicht in eine Debugging-Sitzung. Fragen Sie, was sonst auf der Box jetzt einen Pfad über dieselbe Schnittstelle nehmen könnte und ob irgendetwas davon es sollte. An einer belebten Edge mit Gästenetzen oder überlappenden Partnertunneln lautet die Antwort nicht automatisch nein. Schreiben Sie den Grund neben die Einstellung, denn der nächste Ingenieur findet den Befehl und nicht das Gespräch.

Schutzumfang und NAT sind getrennt

Der Tunnel von Standort zu Standort schützt, was seine Crypto-ACL auswählt. Wenn diese ACL das interne Subnetz der ASA als Quelle nennt, ist der Remote-Access-Pool nicht geschützt, und das Paket wird je nach Verhalten der Plattform bei nicht passendem Verkehr entweder verworfen oder im Klartext gesendet. Fügen Sie den Pool dem geschützten Fluss hinzu, wenn das Design Pool-Adressen bewahrt.

NAT entscheidet dann, ob die Pool-Adresse überlebt. Identity NAT behält sie, und die Filiale sieht 10.77.0.20 als Quelle. Eine Übersetzung ändert den Vertrag: Die Filiale sendet Verkehr nun an die übersetzte Adresse zurück, und ihre eigene Richtlinie muss das akzeptieren. Die Regelreihenfolge entscheidet, ob die Crypto-ACL vor oder nach der Übersetzung greift, also lesen Sie den effektiven Fluss, statt anzunehmen, welche gewinnt.

Löschen Sie nicht die allgemeinen Internet-PAT-Regeln, damit ein einzelner Transitfall funktioniert. Eine gezielte Ausnahme oder eine bewusste Identity-Regel ist leichter zu erklären und zurückzunehmen als ein Loch in der Ausgangsrichtlinie.

Verschlüsselung ist keine Autorisierung

Ein funktionierender Tunnel beweist nur, dass sich zwei Peers über Schlüssel und Selektoren einig sind. Er sagt nichts darüber, ob dieser Benutzer jenen Dienst erreichen darf. Der VPN-Filter oder die Gruppenrichtlinie, die an der Remote-Access-Verbindung hängt, muss das Ziel und den Port der Filiale weiterhin erlauben, und die Schnittstellen-ACL auf dem Außenpfad gilt weiterhin.

Testen Sie die Antwort in beide Richtungen. Eine Verbindung, die gelingt, während ein benachbarter Dienst scheitern sollte, ist aussagekräftiger als ein einzelner erfolgreicher Ping, denn sie zeigt, dass die Richtlinie selektiv und nicht weit offen ist. Wenn der verbotene Test gelingt, ist nicht der Tunnel schuld, sondern die Richtlinie. Halten Sie beide Ergebnisse im Änderungsdatensatz fest, damit die nächste Person weiß, welches Verhalten beabsichtigt war.

Hairpin oder eine zweite Schnittstelle

Hairpin-Transit hält das Design klein und kostet eine globale Einstellung. Eine separate Schnittstelle oder ein routenbasierter Tunnel mit eigener virtueller Schnittstelle isoliert den Transitpfad und gibt Ihnen Richtlinien pro Schnittstelle, zum Preis von Adressierung und einer weiteren Crypto-Map oder einem Profil. Keines ist richtiger; sie scheitern unterschiedlich.

Routenbasierte Designs sind eine andere Anordnung, kein Häkchen in derselben Konfiguration. Wenn Sie zu einem wechseln, gilt die obige Diskussion zur richtlinienbasierten Crypto-ACL nicht mehr, und die Routingtabelle übernimmt die Auswahlarbeit.

Vom echten Client aus prüfen

Eine von der ASA gestartete Probe hat eine andere Quelladresse und durchläuft den Pfad vom Pool zur Filiale nicht. Nutzen Sie packet-tracer zur Prüfung des Fünf-Tupels und öffnen Sie dann eine echte Verbindung vom tatsächlichen Remote-Client, denn der Tracer simuliert und ersetzt nicht das eigene Routing und die Richtlinie des Clients.

Verbinden Sie sich nach einer geplanten Änderung mit einem Dienst, der funktionieren sollte, dann mit einem, der abgelehnt werden sollte, und bestätigen Sie anschließend die Rückroute der Filiale. Die Ciscos Beispiele für VPN-Hairpin-NAT halten Intra-Interface-Erlaubnis, NAT und ACLs sichtbar getrennt, und das ist das mentale Modell, das es zu kopieren lohnt.

Ähnliche Artikel