Jemand fragt, ob das VPN-Subnetz der Filiale auf der ASA „Sicherheitsstufe 0 oder 100“ hat, und die Frage enthält bereits den Denkfehler. Die Sicherheitsstufe ist eine Eigenschaft einer lokalen Schnittstelle und wird in der Schnittstellenkonfiguration von 0 bis 100 vergeben. Ein entferntes Subnetz, das über einen Tunnel ankommt, erwirbt keine, egal wie die Crypto Map geschrieben ist. Deshalb hat die Frage keine numerische Antwort.

Die praktische Anschlussfrage ist besser: Welche Richtlinie lässt die Filiale zum Server durch, und welche hält sie vom Firewall-Gerät selbst fern. Das sind zwei Antworten, und das folgende Verfahren trennt sie.

Sicherheitsstufen gehören zu Schnittstellen

Führen Sie show running-config interface aus, und Sie sehen security-level unter jeder physischen Schnittstelle oder VLAN-Schnittstelle, nicht unter der Tunnelgruppe oder der Crypto Map. Die standardmäßige Freigabe von höher nach niedriger wird zwischen diesen Schnittstellen ausgewertet, weshalb die Zahl das Verhalten von Inspection und impliziter ACL auf dem Pfad ändert, zu dem sie gehört.

Bei einem entschlüsselten VPN-Datenstrom bleibt der Eingang die Outside-Schnittstelle, an der der Tunnel endet, und der Ausgang die Inside-Schnittstelle zum Server. Notieren Sie beide, bevor Sie irgendetwas anfassen. Dieser eine Schritt beseitigt den größten Teil der Verwirrung, weil er aus einer abstrakten Vertrauensfrage ein Schnittstellenpaar macht.

Die ACL-Umgehung hat eine benannte Grenze

sysopt connection permit-vpn ist die Einstellung, an die sich die Leute halb erinnern, wenn sie sagen, VPN-Datenverkehr ignoriere ACLs. Sie überspringt tatsächlich die Schnittstellen-ACL für Datenverkehr, der als VPN-Datenverkehr gilt, und der Parameterleitfaden für 9.x grenzt sie nach Schnittstelle und Richtung ein, statt eine globale Ausnahme zu erklären.

Prüfen Sie erst die Konfiguration, bevor Sie aus dem Gedächtnis argumentieren:

  • show running-config all sysopt zeigt den tatsächlich wirksamen Wert, nicht nur die nicht standardmäßigen Zeilen.
  • show running-config access-group zeigt, welche ACL auf welche Schnittstelle und Richtung angewendet wird.
  • show vpn-sessiondb detail l2l bestätigt, welche Tunnelgruppe und welchen Filter die Sitzung tatsächlich verwendet.

Diese Einstellung abzuschalten, um den VPN-Zugriff zu verschärfen, ist eine Änderung mit großer Reichweite. Sie unterwirft jeden passenden VPN-Datenstrom wieder der Outside-ACL, was funktionierende Tunnel meist auf eine Weise bricht, die mit der Filiale, nach der gefragt wurde, nichts zu tun hat.

Den Filter lesen, der an der Sitzung hängt

Die eigentliche Steuerung pro Tunnel ist der VPN-Filter: eine ACL, auf die eine Gruppenrichtlinie oder ein Benutzername verweist und die nach der Entschlüsselung und vor der Verschlüsselung angewendet wird. Ein Filter auf Benutzerebene überschreibt den Wert auf Gruppenebene, sodass zwei Personen in derselben Tunnelgruppe unterschiedlichen effektiven Zugriff haben können.

Bestätigen Sie die Rangfolge, statt sie anzunehmen. show running-config group-policy <name> zeigt den Gruppenwert, und show running-config username <name> zeigt, ob ein benutzerspezifischer Wert existiert. Wenn beides existiert, gewinnt der Benutzerwert. Vergleichen Sie dann die Einträge dieser ACL mit dem Datenstrom, der Sie interessiert, und zwar in der Richtung, in der der Filter ausgewertet wird.

Ein Filter, der den Anwendungsserver erlaubt, sagt nichts über die Verwaltung aus. Das sind getrennte Regeln auf einem getrennten Pfad.

Eine Freigabe und eine Sperre prüfen

Packet-Tracer ist der schnellste Weg, die Entscheidung zu sehen, ohne zu warten, bis ein Benutzer sie meldet. Geben Sie ihm den Datenstrom auf der entschlüsselten Seite und lassen Sie ihn die ACL-, NAT- und Inspection-Stufen benennen, die er durchläuft.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. Lesen Sie die Ergebniszeile: Sie nennt die ACL, die das Paket zugelassen oder verworfen hat.
  3. Wiederholen Sie das mit dem Verwaltungsziel auf der Inside-Schnittstelle und bestätigen Sie eine Sperre.
  4. Wiederholen Sie es nach jeder Änderung noch einmal, damit sowohl der Zustand vorher als auch nachher festgehalten ist.

Prüfen Sie dann mit echtem Datenverkehr: eine erfolgreiche Anwendungsanfrage aus der Filiale und einen fehlgeschlagenen SSH-Versuch auf die ASA. Packet-Tracer modelliert den Pfad; ein laufender Datenstrom beweist, dass das Modell gestimmt hat.

Die Änderung rückgängig machen, die es zum Laufen brachte

Wenn die Lösung darin bestand, die ACL-Umgehung zu deaktivieren oder einen Filter zu erweitern, behalten Sie die vorherige Konfiguration. Ein show run-Mitschnitt der betroffenen Objekte, vor der Änderung gespeichert, reicht aus, um sie wiederherzustellen; die ASA-Konfiguration ist zeilenorientiert, das Zurücknehmen bedeutet also, die alten Zeilen erneut einzugeben, nicht eine Datei wiederherzustellen.

Halten Sie das Schnittstellenpaar, den wirksamen Filter, den ACL-Namen aus dem Packet-Tracer und die genauen geänderten Befehle fest. Diese Aufzeichnung macht aus der nächsten Überprüfung einen Fünf-Minuten-Check statt einer weiteren Debatte über Vertrauensstufen.

Ähnliche Artikel