SSH a una ASA remota a través de la VPN del sitio: paso a paso

Apunta un cliente SSH a la dirección interna de la ASA remota y la sesión muere al conectar. El cortafuegos responde desde su propio sitio, el túnel aparece y, sin embargo, nada escucha en el puerto 22. En la mayoría de estos casos el paquete nunca llega a la admisión de gestión, porque el camino que se prueba nunca se diseñó como camino de gestión. Siga el flujo de abajo en orden y el fallo deja de moverse.

Elija la dirección que realmente administra

Tres diseños se parecen y se comportan de forma distinta: alcanzar la dirección pública de la ASA orientada a la VPN, alcanzar una interfaz interna mediante IPsec y alcanzar una interfaz de gestión dedicada. Anote la dirección de origen del administrador, la dirección exacta de destino y TCP 22 antes de tocar ningún permiso. Todo lo posterior depende de ese par.

Un túnel que transporta dos VLAN de servidores puede no transportar en absoluto la dirección de la interfaz del cortafuegos ni la subred de gestión del administrador. Revise la lista de tráfico interesante de la política de sitio a sitio y confirme que la dirección propia de la ASA aparece como destino, no solo las subredes que lo atraviesan.

Como el destino es el propio cortafuegos, la admisión de gestión es independiente de las reglas para el tráfico reenviado. Una ACL que deja a los clientes llegar a servidores detrás de la ASA no habilita por sí sola la administración SSH del dispositivo, y arreglar la regla de reenvío no moverá este fallo.

management-access es específica de la interfaz

El comando management-access indica a la ASA que acepte conexiones de gestión en una interfaz concreta cuando llegan por VPN. No crea una ruta, no añade un permiso SSH y no se aplica a todas las interfaces a la vez. Si la interfaz de destino no es la indicada, la conexión se descarta antes de la autenticación.

Aquí muerden dos exclusiones. Las interfaces solo de gestión quedan fuera de este mecanismo, y la guía de gestión de ASA 9.20 señala que la pila CiscoSSH predeterminada no admite SSH entre interfaces por VPN, mientras que la pila ASA SSH sí lo hace. Confirme la pila activa en la versión desplegada antes de dedicar tiempo a las rutas.

Cuatro puertas antes del aviso de inicio de sesión

Entre el cliente y el aviso de nombre de usuario hay cuatro puertas independientes: una coincidencia de ruta y túnel para el par de gestión, una ACL de interfaz que permite TCP 22 hacia la dirección de la ASA, un permiso ssh que cubre el origen del administrador y una autenticación AAA para ese usuario. Cada una puede descartar el paquete sin decir al cliente qué puerta se cerró.

Utilice packet-tracer para ver qué puerta falla antes de cambiar nada: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. El rastro nombra la ACL, la etapa NAT y la decisión to-the-box, lo que suele bastar para separar un problema de enrutamiento de un problema de admisión.

Escriba el permiso estrecho, no el amplio

Limite el permiso a la subred administrativa aprobada y a la interfaz que recibe el tráfico del túnel: ssh 10.10.5.0 255.255.255.0 inside. Emparéjelo con un método de autenticación como aaa authentication ssh console LOCAL y una cuenta local con nombre, en lugar de abrir todos los orígenes en la interfaz externa.

Mantenga coherentes la ACL de interfaz y el permiso ssh. Un permiso para una subred que la ACL bloquea sigue fallando, y una ACL que permite la subred sin una entrada ssh correspondiente falla en la puerta siguiente. Ambas afirmaciones describen el mismo camino desde capas distintas, así que revíselas juntas en la configuración en ejecución.

Verifique desde el host nombrado y vuelva a estrechar

Abra una sesión nueva desde el host de gestión nombrado en lugar de desde su escritorio, y confirme en la ASA qué dirección de origen y qué interfaz usó la conexión. Revise las sesiones activas y la sección SSH de la configuración en ejecución mientras la sesión está abierta, luego ciérrela y elimine cualquier permiso temporal que haya añadido para las pruebas. Si la sesión aparece pero cae justo después del inicio de sesión, el problema restante es la autorización y no la accesibilidad. Registre la interfaz y el origen en el registro de cambios para que la siguiente persona no repita el diagnóstico.

Mantenga la consola u otra ruta de recuperación aprobada de forma independiente disponible durante todo el cambio. Cuando la ruta privada funcione, confirme que las fuentes públicas y los usuarios de VPN no relacionados no obtuvieron el mismo acceso, porque un camino de gestión que funciona para todos es un problema distinto del que usted empezó.