Warum TACACS+-Anfragen der ASA Ihren Filial-VPN-Tunnel umgehen

Der Filialtunnel steht, Benutzer authentifizieren sich am entfernten TACACS+-Server, und die eigene Anmeldung der Firewall läuft trotzdem in einen Timeout. Die Ursache ist kein Fehler im Tunnel: Ein LAN-to-LAN-Tunnel überträgt Verkehr, der zu seinen Selektoren passt, und der Management-Verkehr, den die ASA über sich selbst erzeugt, ist ein eigener Fluss mit eigener Quelladresse. Die meisten Teams entdecken das während eines Änderungsfensters, wenn das einzige Administratorkonto dasjenige ist, das scheitert. Behandeln Sie die von der ASA ausgehende AAA-Sitzung als einen Fluss, den Sie entwerfen müssen, nicht als Nebenwirkung einer Konnektivität, die ohnehin funktioniert.

Die ASA ist der Client, und ihr eigener Verkehr braucht einen eigenen Pfad

Wenn die Firewall einen TACACS+-Server kontaktiert, ist die Firewall ein Client wie jeder andere, mit dem Unterschied, dass niemand bewusst eine Route dafür konfiguriert hat. Ihre Pakete stammen von einer Interface-Adresse des Geräts, sie werden lokal erzeugt statt weitergeleitet, und sie müssen geroutet, übersetzt und durch Policy geschützt werden, genau wie Benutzerverkehr. Ein Site-to-Site-Tunnel, der ein Benutzersubnetz schützt, schützt diese Management-Quelle nicht automatisch, weil die Verkehrsauswahl auf Adressen und nicht auf Absichten beruht.

Notieren Sie die Adresse, die der Server sehen soll. Wenn Sie sie nicht in einer Zeile nennen können, haben Sie noch kein Design.

Das Interface in der aaa-server-Zeile ist keine Dekoration

Auf der ASA nimmt der aaa-server-Host-Eintrag eine Interface-Zuordnung in Klammern an, und Ciscos Befehlsreferenz für AAA-Hosts beschreibt sie als das Interface, auf dem der Authentifizierungsserver liegt. Genau diese Zuordnung bindet die Anfrage an ein Interface und an die Policy, die dieses Interface anwendet. Wählt man sie nach dem Interface, das ins Internet zeigt, oder lässt stehen, was von der letzten Migration übrig war, entsteht eine Quelladresse, für die der entfernte Server und der Tunnel nie gebaut wurden.

inside ist nur dann die richtige Antwort, wenn das genannte Interface die Adresse trägt, die Ihr Design als Quelle verwenden will. Auf einem Filialgerät ist das oft so; auf einem Gerät mit mehreren privaten Segmenten vielleicht nicht.

Eine geänderte Zuordnung bedeutet, den Eintrag neu anzulegen

Dieselbe Befehlsreferenz dokumentiert eine Bearbeitungseinschränkung, die Leute bei Umstellungen erwischt: Das Interface eines bestehenden Hosts zu ändern erfordert, den Host-Eintrag zu entfernen und neu anzulegen. Eine Konfiguration, die bearbeitet aussieht, ist möglicherweise nicht wirksam geworden, und der nächste Anmeldeversuch geht weiterhin von der alten Adresse aus. Planen Sie das als Löschen und Hinzufügen mit einer Kopie des ursprünglichen Eintrags vor sich, nicht als Änderung an Ort und Stelle.

Sind mehrere Server definiert, ändern Sie einen und testen ihn, bevor Sie die übrigen anfassen, damit ein Fehler nicht alle administrativen Wege auf einmal sperrt.

Selektoren, Übersetzung und Rückweg zusammen prüfen

Drei Dinge müssen zusammenpassen, damit die Anfrage ankommt. Die Traffic-Selektoren des Tunnels, oder der Tunnel-Interface-Schutz, falls Sie einen betreiben, müssen die eigene Quelle der ASA und die Adresse des Servers enthalten; eine Selektorenliste, die für Benutzersubnetze gebaut wurde, tut das meist nicht. Jede NAT-Regel auf dem Pfad muss diese Quelle konsistent übersetzen, denn der Server autorisiert eine Netzwerkgeräte-Identität, die die Adresse einschließt, die er sieht. Und der Rückweg muss existieren, was bei einem policybasierten Tunnel bedeutet, dass die Gegenseite einen passenden Selektor in der anderen Richtung hat.

Prüfen Sie auf der Serverseite Geräteidentität, gemeinsames Geheimnis und administrative Policy getrennt. TACACS+ hält Authentifizierung, Autorisierung und Accounting als getrennte Operationen, eine Ablehnung nach abgeschlossenem Austausch ist also eine Policy-Antwort, kein Transportfehler. Lesen Sie sie als Netzwerkproblem, suchen Sie an der falschen Stelle.

Halten Sie das Geheimnis beim Debuggen aus Mitschnitten, Tickets und Transkripten heraus, und denken Sie daran, dass die Quelladresse, die der Server protokolliert, diejenige ist, die Ihr Design erklären muss.

Nehmen Sie die Änderung vor, ohne sich auszusperren

Nutzen Sie eine Konsole oder einen unabhängigen Management-Pfad, während Sie die entfernte administrative Authentifizierung ändern, und halten Sie einen genehmigten lokalen Fallback bereit, bis der neue Pfad eine echte Anmeldung getragen hat. Validieren Sie dann eng: ein Server, ein Gerät, eine erfolgreiche Authentifizierung mit der auf beiden Seiten beobachteten Quelladresse.

Halten Sie den Fluss auf einer eigenen Seite fest: Ursprungs-Interface und -Adresse, entfernter Server, geschützter Pfad und die Person, der die Autorisierungs-Policy gehört. Ein späterer Interface- oder Tunnelwechsel lässt sich dann bewerten, ohne zu raten, welchen der beiden Flüsse er betrifft.