Split-Tunnel befreit einen öffentlichen Host nicht von den NAT-Regeln der ASA

Split-Tunneling wird üblicherweise als ein Weg beschrieben, Unternehmensverkehr im Tunnel zu halten und den Rest des Internets außerhalb der Firewall. Beide Hälften dieser Beschreibung sind auf dieselbe Weise falsch. Split-Tunneling ist eine Routing-Entscheidung des Clients, und eine Routing-Entscheidung sagt nichts darüber aus, was mit dem Paket geschieht, nachdem es den Headend erreicht hat.

Ein einziger Partnerdienst auf einer öffentlichen Adresse, der darauf besteht, die Adresse Ihrer Zentrale zu sehen, genügt, um die Erzählung zu zerlegen.

Der Mythos: Split-Tunnel nimmt die Firewall aus dem Pfad

Die Annahme ist, dass jedes Ziel außerhalb der privaten Bereiche auf der lokalen Internetverbindung bleibt, sodass die Firewall es nie sieht und nie eine Regel dafür braucht. Das gilt nur, solange das Ziel nicht in der Tunnelliste steht. Sobald ein Administrator einen öffentlichen Host in die Split-Include-ACL aufnimmt, schickt der Client diesen Verkehr in den Tunnel, und die ASA muss ihn wie jeden anderen entschlüsselten Flow routen, filtern und übersetzen. Am Client hat sich nichts geändert außer der Zielliste.

Der Client ist dadurch nicht zum Router geworden. Er hat die Richtlinie befolgt, die Sie ihm gegeben haben.

Was eine Split-Include-Route tatsächlich tut

In einem Remote-Access-Setup auf einer Cisco ASA enthält die Gruppenrichtlinie split-tunnel-policy tunnelspecified und eine split-tunnel-network-list, die eine Standard-ACL benennt. Jede Permit-Zeile in dieser ACL ist ein Ziel, das der Client in den Tunnel schicken soll, und alles andere nutzt weiterhin die lokale Standardroute.

Einen Host hinzuzufügen ist eine einzige Zeile, und sie ist der einzige Teil der Änderung, den der Client sehen kann: access-list RA-SPLIT standard permit host 203.0.113.20.

Verbinden Sie den Client danach neu. Die Richtlinie wird beim Verbindungsaufbau ausgetauscht, eine bestehende Sitzung behält also die alte Liste und lässt die Änderung so aussehen, als hätte sie nichts bewirkt.

Das Paket kommt auf derselben Schnittstelle an und geht dort wieder hinaus

Verfolgen Sie nun den Flow nach der Entschlüsselung. Das Paket kam über den VPN-Tunnel auf der Outside-Schnittstelle herein, sein Ziel ist eine öffentliche Adresse, und die Routingtabelle schickt es über dieselbe Outside-Schnittstelle wieder Richtung Internet hinaus. Verkehr, der auf einer Schnittstelle hereinkommt und sie wieder verlässt, wird verworfen, es sei denn, die ASA darf es zulassen – genau das bewirkt same-security-traffic permit intra-interface. Ohne diese Einstellung scheitert die Verbindung auf eine Weise, die wie ein Routingproblem aussieht, aber keines ist.

Diese Einstellung ist global. Sie erlaubt Hairpinning für jeden Flow, der es braucht, nicht nur für diesen Partnerhost, deshalb gehört sie in eine geprüfte Änderung statt in einen Schnelltest.

Warum ein zielbezogenes PAT nicht optional ist

Die Quelladresse im entschlüsselten Paket ist weiterhin die VPN-Adresse des Clients, typischerweise aus einem Pool wie 10.77.0.0/24. Diese Adresse hat im öffentlichen Internet keine Route, also antwortet der Partner entweder nie oder ins Leere.

Die Übersetzung korrigiert die Quelle und lässt das Ziel unangetastet. Da die Objekte anderswo bereits definiert sind, hat eine manuelle, auf dieses Ziel beschränkte Regel diese Form:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Der Teil destination static ist wichtig. Lässt man ihn weg, wird die Regel zu einer breiten Übersetzung, die weit mehr Verkehr erfassen kann als beabsichtigt, und eine breite Identity-Regel weiter oben in der Reihenfolge kann diese hier vollständig schlagen. Prüfen Sie show nat detail und die Abschnittsreihenfolge, bevor Sie annehmen, dass Ihre Regel die passende ist.

Interface-PAT bedeutet außerdem, dass der Partner die Schnittstellenadresse der ASA sieht, die weiter oben nochmals übersetzt werden kann. Wenn der Vertrag eine Adresse nennt, bestätigen Sie sie Ende zu Ende statt an einem einzelnen Hop.

Beweisen Sie es mit dem richtigen Testziel

Verwenden Sie den Partnerhost selbst, nicht eine allgemeine What-is-my-IP-Seite. Diese Seite liegt fast sicher außerhalb der Split-Liste, meldet also Ihre lokale Internetadresse und sagt nichts über diesen Pfad aus. Öffnen Sie eine neue Verbindung zum Partnerdienst und fragen Sie, welche Quelle er beobachtet hat, oder führen Sie packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed aus und lesen Sie die NAT- und Routing-Stufen Zeile für Zeile. Ein Traceroute vom Client ist eine schwächere Prüfung, weil er den Pfad zeigt, der bereits stattgefunden hat, statt der Richtlinie, die ihn gewählt hat.

Prüfen Sie dann, was sich nicht ändern darf. Eine gewöhnliche Website muss weiterhin über die lokale Verbindung hinausgehen, und eine private Ressource in der Tunnelliste muss weiterhin erreichbar sein. Eine Änderung, die den Partner repariert und eines von beiden bricht, ist ein anderer Fehler.

Die funktionierende Version dieses Designs ist kurz: ein Host in der Split-ACL, Hairpin-Erlaubnis, eine zielbezogene PAT-Regel. Alles andere in der Geschichte ist der Mythos.