SSH zu einer entfernten ASA über das Site-VPN: Schritt für Schritt

Sie richten einen SSH-Client auf die interne Adresse der entfernten ASA und die Sitzung stirbt beim Verbinden. Die Firewall antwortet von ihrem eigenen Standort, der Tunnel erscheint, und dennoch lauscht nichts auf Port 22. In den meisten dieser Fälle erreicht das Paket nie die Verwaltungszulassung, weil der getestete Pfad nie als Verwaltungspfad entworfen wurde. Gehen Sie den Ablauf unten der Reihe nach durch, und der Fehler hört auf, sich zu verschieben.

Wählen Sie die Adresse, die Sie tatsächlich verwalten

Drei Entwürfe sehen ähnlich aus und verhalten sich anders: die öffentliche, VPN-zugewandte Adresse der ASA erreichen, ein internes Interface über IPsec erreichen und ein dediziertes Verwaltungsinterface erreichen. Notieren Sie die Quelladresse des Administrators, die genaue Zieladresse und TCP 22, bevor Sie eine Berechtigung anfassen. Alles Weitere hängt von diesem Paar ab.

Ein Tunnel, der zwei Server-VLANs trägt, trägt möglicherweise gar nicht die Interface-Adresse der Firewall oder das Verwaltungssubnetz des Administrators. Prüfen Sie die Liste des interessanten Verkehrs für die Site-to-Site-Richtlinie und bestätigen Sie, dass die eigene Adresse der ASA als Ziel erscheint, nicht nur die Subnetze, die sie durchlaufen.

Weil das Ziel die Firewall selbst ist, ist die Verwaltungszulassung getrennt von Regeln für weitergeleiteten Verkehr. Eine ACL, die Clients zu Servern hinter der ASA lässt, aktiviert nicht eigenständig die SSH-Verwaltung des Geräts, und eine Korrektur der Weiterleitungsregel verschiebt diesen Fehler nicht.

management-access ist interface-spezifisch

Der Befehl management-access weist die ASA an, Verwaltungsverbindungen zu einem benannten Interface anzunehmen, wenn sie über VPN eintreffen. Er erstellt keine Route, er fügt keine SSH-Berechtigung hinzu, und er gilt nicht für alle Interfaces gleichzeitig. Ist das Zielinterface nicht das benannte, wird die Verbindung vor der Authentifizierung verworfen.

Zwei Ausschlüsse greifen hier. Reine Verwaltungsinterfaces liegen außerhalb dieses Mechanismus, und der Verwaltungsleitfaden für ASA 9.20 merkt an, dass der standardmäßige CiscoSSH-Stack SSH zwischen Interfaces über VPN nicht unterstützt, während der ASA-SSH-Stack es tut. Bestätigen Sie den aktiven Stack auf der eingesetzten Version, bevor Sie Zeit in Routen investieren.

Vier Tore vor der Anmeldeaufforderung

Zwischen dem Client und der Benutzernamenabfrage stehen vier unabhängige Tore: eine Route- und Tunnelübereinstimmung für das Verwaltungspaar, eine Interface-ACL, die TCP 22 zur ASA-Adresse erlaubt, eine ssh-Berechtigung, die die Quelle des Administrators abdeckt, und eine AAA-Authentifizierung für diesen Benutzer. Jedes kann das Paket verwerfen, ohne dem Client zu sagen, welches Tor geschlossen wurde.

Nutzen Sie packet-tracer, um zu sehen, welches Tor fehlschlägt, bevor Sie etwas ändern: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Die Spur nennt die ACL, die NAT-Stufe und die to-the-box-Entscheidung, was meist genügt, um ein Routingproblem von einem Zulassungsproblem zu trennen.

Schreiben Sie die enge Berechtigung, nicht die breite

Begrenzen Sie die Berechtigung auf das freigegebene administrative Subnetz und das Interface, das den Tunnelverkehr empfängt: ssh 10.10.5.0 255.255.255.0 inside. Kombinieren Sie sie mit einer Authentifizierungsmethode wie aaa authentication ssh console LOCAL und einem benannten lokalen Konto, statt jede Quelle auf dem Außeninterface zu öffnen.

Halten Sie die Interface-ACL und die ssh-Berechtigung konsistent. Eine Berechtigung für ein Subnetz, das die ACL blockiert, schlägt weiterhin fehl, und eine ACL, die das Subnetz ohne passenden ssh-Eintrag erlaubt, schlägt am nächsten Tor fehl. Beide Aussagen beschreiben denselben Pfad aus verschiedenen Schichten, prüfen Sie sie daher gemeinsam in der laufenden Konfiguration.

Prüfen Sie vom benannten Host aus und grenzen Sie dann erneut ein

Öffnen Sie eine neue Sitzung vom benannten Verwaltungshost statt von Ihrem Schreibtisch aus und bestätigen Sie auf der ASA, welche Quelladresse und welches Interface die Verbindung verwendet hat. Prüfen Sie die aktiven Sitzungen und den SSH-Abschnitt der laufenden Konfiguration, während die Sitzung besteht, schließen Sie sie dann und entfernen Sie jede vorübergehende Berechtigung, die Sie zum Testen hinzugefügt haben. Erscheint die Sitzung, bricht aber direkt nach der Anmeldung ab, ist das verbleibende Problem die Autorisierung und nicht die Erreichbarkeit. Notieren Sie Interface und Quelle im Änderungsprotokoll, damit die nächste Person die Diagnose nicht wiederholt.

Halten Sie die Konsole oder einen anderen unabhängig genehmigten Wiederherstellungspfad während der gesamten Änderung verfügbar. Sobald der private Pfad funktioniert, bestätigen Sie, dass öffentliche Quellen und unbeteiligte VPN-Benutzer keinen gleichwertigen Zugang erhalten haben, denn ein Verwaltungspfad, der für alle funktioniert, ist ein anderes Problem als das, mit dem Sie begonnen haben.