Warum ein ASA-Fernbenutzer das Subnetz erreicht, aber nicht die Anwendung
Routen beweisen, dass der Tunnel funktioniert, nicht dass der Benutzer die Anwendung öffnen darf. Lesen Sie den Filter, den die Sitzung erhalten hat, und testen Sie dann eine erlaubte und eine verweigerte Verbindung.
Ihr Benutzer verbindet sich, erhält eine Adresse, pingt einen Server im Anwendungs-Subnetz an und kann den Dienst darauf trotzdem nicht öffnen. Diese Kombination ist auf einer ASA normal, weil ein erfolgreicher Tunnel und eine nutzbare Berechtigung von unterschiedlichen Einstellungen entschieden werden. Die Split-Tunnel-Liste wählte aus, welche Ziele in den Tunnel gelangten; ein VPN-Filter und die eigenen Zugriffsregeln des Ziels entscheiden, was die entschlüsselte Anfrage erreichen darf. Arbeiten Sie die drei Entscheidungen der Reihe nach ab, statt die Routenliste zu erweitern, bis sich etwas ändert.
Drei Entscheidungen, die leicht zu verwechseln sind
Die Zulassung beantwortet, ob der Benutzer den Tunnel überhaupt aufbauen darf: Anmeldedaten, Zertifikat und ein etwaiger zweiter Faktor. Die Routenauswahl beantwortet, welche Ziele der Client in diesen Tunnel sendet. Die Autorisierung beantwortet, ob die entschlüsselte Anfrage den Dienst erreichen darf. Nur die dritte erzeugt den Fehler, den der Benutzer meldet.
Ein schneller Weg, sie zu unterscheiden, ist zu fragen, was eine Änderung kaputt machen würde. Eine Route aus der Split-Liste zu entfernen, stoppt den Verkehr zu diesem Subnetz, ohne etwas zu gewähren; eine ACE zum VPN-Filter hinzuzufügen, gewährt ein Ziel, ohne zu ändern, was der Client tunnelt.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Lesen Sie den Filter, den die Sitzung tatsächlich erhalten hat
Beginnen Sie bei der laufenden Sitzung und nicht bei der Konfiguration, die Ihrer Meinung nach gilt. show vpn-sessiondb detail anyconnect gibt die zugewiesene Gruppenrichtlinie und den Namen des Filters aus, der an diese Sitzung gebunden ist. Ist das Feld leer, erzwingt kein Filter etwas und die Blockierung kommt von woanders.
Lesen Sie dann die Richtlinie, der der Wert gehört, einschließlich der Standardwerte, denn ein Filter kann geerbt werden, statt dort geschrieben zu sein, wo Sie nachsehen:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Vergleichen Sie den Filternamen der Sitzung mit der ACL, die Sie gerade bearbeitet haben. Eine ähnlich benannte ACL, die der Benutzer nie erhalten hat, kann die Ressourcenrichtlinie dieser Sitzung nicht ändern, und das ist der häufigste Grund, warum eine korrekt aussehende Änderung keine Wirkung hat.
Die Rangfolge erklärt den Rest. Für die Filtereinstellung hat ein DAP-Datensatz Vorrang vor Benutzernamenattributen, und Benutzernamenattribute haben Vorrang vor der Gruppenrichtlinie. Wenn eine Sitzung einen Filter zeigt, den Sie nicht erwartet haben, suchen Sie nach einer DAP-Richtlinie, die zu diesem Benutzer passt, bevor Sie die Gruppe anfassen.
Die Split-Liste und der Filter sind getrennte Felder
Auf ASA 9.x enthält die Gruppenrichtlinie split-tunnel-network-list und vpn-filter als verschiedene Einstellungen, und der Gruppenrichtlinien-Leitfaden für 9.22 dokumentiert sie aus genau diesem Grund getrennt. Die Netzwerkliste ist ein Routing-Hinweis an den Client; der Filter ist eine Zugriffskontrollliste, die auf entschlüsselten Verkehr angewendet wird.
Diese Unterscheidung zählt, wenn ein Benutzer einen einzigen HTTPS-Dienst in einem Subnetz braucht. Setzen Sie das Subnetz in die Split-Liste, damit die Pakete in den Tunnel gelangen, und erlauben Sie dann nur diesen Dienst im Filter. Die Routenliste zu erweitern autorisiert nichts, und sie zu verkleinern ist kein Durchsetzungsmechanismus.
Prüfen Sie, ob eine Interface-ACL überhaupt im Pfad liegt
Entschlüsselter Fernzugriffsverkehr durchläuft nicht immer die Outside-Interface-ACL, wie man annimmt. Wo sysopt connection permit-vpn aktiviert ist, wendet die ASA ihre dokumentierte VPN-Umgehung für diesen Verkehr an, während geltende VPN-Filter danach weiterhin greifen. Prüfen Sie die Einstellung mit show run all sysopt statt aus dem Topologiediagramm zu schließen.
So oder so bleiben die eigene Firewall des Zielhosts und die Autorisierung der Anwendung im Pfad. Eine ASA-Regel, die TCP 443 erlaubt, bringt die Anwendung nicht dazu, den Benutzer zu akzeptieren.
Akzeptieren Sie die Änderung auch mit einer verweigerten Verbindung
Ein erlaubter Test allein beweist sehr wenig, weil ein funktionierender Tunnel dasselbe erste Paket erzeugt, ob ein Filter existiert oder nicht. Öffnen Sie den vorgesehenen Dienst vom Client aus, versuchen Sie dann ein Ziel, das geschlossen bleiben soll, und bestätigen Sie, dass es aus dem richtigen Grund scheitert.
Notieren Sie vier Fakten, wenn Sie das Ticket schließen: die zugelassene Identität, die Richtlinie und den Filter, die die Sitzung tatsächlich erhalten hat, die Ziele in der Split-Liste und die Ressource, die der Benutzer erreichen durfte. Diese vier erklären, wo der Verkehr kontrolliert wird, ohne eine Routenliste in eine Firewall zu verwandeln.
Wenn der Dienst weiterhin ablehnt, nachdem der Filter ihn erlaubt, gehen Sie zum Host: Listenadresse, Host-Firewall und die eigene Benutzerzuordnung der Anwendung. Der Tunnel hat an diesem Punkt seine Aufgabe erfüllt, und weitere ASA-Änderungen fügen nur Risiko hinzu.