Standort-VPN funktioniert, doch ASA-Logs kommen nicht: Quelladresse prüfen

Interne Hosts erreichen den entfernten Collector, und ihre Syslog-Zeilen erscheinen. Die eigenen Meldungen der ASA zu denselben Sitzungen kommen nie an. Weder der Collector noch der Tunnel haben ein Problem, und genau das verwirrt. Die Firewall sendet ihre Logs von einer Quelle, für deren Schutz der Tunnel nie gebaut wurde.

Was ankommt und was nicht

Trennen Sie zunächst zwei Ströme, die auf einem Dashboard identisch aussehen. Weitergeleiteter Verkehr passiert die ASA: Ein LAN-Host sendet an den Collector, die ASA gleicht ihn mit der Tunnelrichtlinie ab, verschlüsselt ihn, und der Collector sieht die Adresse des Hosts. Erzeugter Verkehr beginnt auf der ASA selbst: Die Box baut ein Syslog-Paket, wählt ein Ausgangsinterface und eine Quelle und fragt erst dann, ob eine Tunnelrichtlinie passt. Der erste Strom beweist, dass der Tunnel funktioniert, und sagt nichts über den zweiten.

Ein gepuffertes Ereignis auf dem Gerät ist ebenfalls kein Beweis für die entfernte Zustellung, denn das Log kann lokal existieren und nie übertragen worden sein. Prüfen Sie die Empfangszähler des Collectors, bevor Sie den Tunnel beschuldigen, denn ein leerer Zähler ist ein anderer Befund als einer, der wächst.

Eine erzeugte Meldung ist kein weitergeleiteter Verkehr

Wenn die ASA ein Paket selbst erzeugt, proxyiert sie keinen LAN-Host. Die Quelle stammt vom Ausgangsinterface oder aus einer expliziten Quelleneinstellung, und das Paket durchläuft dieselbe Routensuche und dieselben Richtlinienprüfungen wie alles andere, was die Box sendet. Das heißt, der VPN-Selektor muss die Adresse enthalten, die die ASA tatsächlich verwendet, und das ist häufig ihr Außeninterface statt eines internen Subnetzes.

Schützt die Richtlinie 10.20.0.0/24 und verwendet die ASA ihre Außenadresse als Quelle, verlässt das Log-Paket entweder im Klartext einen Collector, den es nicht erreichen kann, oder es wird verworfen. Beide Ergebnisse sehen von der Collectorseite identisch aus. Dieselbe Überlegung gilt für Verwaltungsverkehr, weshalb management-access eine eigene Designentscheidung ist.

Welche Quelle die ASA auf die Leitung legt

Ermitteln Sie die Quelle empirisch statt per Annahme. Ein Mitschnitt am Ausgangsinterface während einer Testmeldung zeigt die tatsächliche Quelle und das Ziel, und er kostet weniger Zeit als das Lesen von drei Konfigurationsabschnitten. Vergleichen Sie diese Adresse mit dem lokalen Selektor des Tunnels.

Manche Releases erlauben, die Logquelle an ein Interface zu binden, und die Kommandoreferenz für Ihre Version ist die maßgebliche Auskunft darüber, ob diese Option existiert und was sie ändert. Ein source-interface-Kommando von einer anderen Cisco-Plattform ist auf einer ASA nicht automatisch gültig.

Wenn Sie die Quelle ändern, tun Sie es bewusst und halten Sie es fest, denn Collector-ACLs und jede auf Syslog aufgebaute Korrelation hängen davon ab.

Passen Sie den Selektor an den Logstrom an

Sobald die Quelle bekannt ist, prüfen Sie drei Dinge der Reihe nach: die Krypto-ACL oder den richtlinienbasierten Selektor, der entscheidet, welcher Verkehr interessant ist, die Route, die entscheidet, wohin das Paket geht, und jede NAT-Regel, die die Quelle vor der Verschlüsselung umschreiben könnte. Ein Paket, das zur Route, aber nicht zum Selektor passt, wird nicht getunnelt, und ein von NAT umgeschriebenes Paket passt möglicherweise zu keinem von beiden.

Die Collectorseite hat eigene Anforderungen: eine ACL, die die Quelle der ASA zulässt, eine Rückroute und ein lauschender Dienst auf dem konfigurierten Port. Auch der Transport zählt hier, denn TCP- und TLS-Logging verhalten sich auf einem teilweise blockierten Pfad anders als UDP. Ändern Sie jeweils ein Element, sonst sagt Ihnen der nächste Mitschnitt nicht, welche Änderung zählte.

Prüfen Sie am Collector und halten Sie dann die Quelle fest

Bestätigen Sie, dass die Meldung ankommt, und notieren Sie dann die Quelladresse, die die ASA verwendet hat, den Selektor, der sie transportiert hat, und den Schweregrad, mit dem Sie getestet haben.

Diese Aufzeichnung macht die nächste ACL-Änderung oder Selektoranpassung am Collector zu einer Zwei-Minuten-Prüfung statt zu einer erneuten Entdeckung. Sie dokumentiert außerdem, welcher der beiden Ströme jemals validiert wurde, und genau diesen Teil lassen die meisten Runbooks aus. Kommt die Meldung weiterhin nicht an, senken Sie die Schweregradschwelle vorübergehend und testen Sie gegen ein einziges Ziel.

Ciscos FAQ zur ASA-Protokollierung dokumentiert einen Fall mit externer Quelle, der die entsprechende Definition geschützten Verkehrs braucht, und sein Beispiel mit interner Quelle umfasst sowohl einen Loghost im Inneren als auch management-access im Inneren. Behandeln Sie die dokumentierte Kombination und den Softwarekontext zusammen, statt anzunehmen, eine kopierte Zeile passe zu jeder Konfiguration.

Ein Tunnel, der LAN-Verkehr trägt, ist kein Tunnel, der die eigene Stimme der Firewall trägt.