SSH a unha ASA remota a través da VPN do sitio: paso a paso

Apunte un cliente SSH ao enderezo interno da ASA remota e a sesión morre ao conectar. A devasa responde desde o seu propio sitio, o túnel aparece e, aínda así, nada escoita no porto 22. Na maioría destes casos o paquete nunca chega á admisión de xestión, porque o camiño que se proba nunca se deseñou como camiño de xestión. Siga o fluxo de abaixo en orde e o fallo deixa de moverse.

Escolla o enderezo que realmente administra

Tres deseños parecen iguais e compórtanse de forma distinta: chegar ao enderezo público da ASA orientado á VPN, chegar a unha interface interna mediante IPsec e chegar a unha interface de xestión dedicada. Anote o enderezo de orixe do administrador, o enderezo exacto de destino e TCP 22 antes de tocar ningún permiso. Todo o posterior depende dese par.

Un túnel que transporta dúas VLAN de servidores pode non transportar en absoluto o enderezo da interface da devasa nin a subrede de xestión do administrador. Revise a lista de tráfico interesante da política de sitio a sitio e confirme que o enderezo propio da ASA aparece como destino, non só as subredes que o atravesan.

Como o destino é a propia devasa, a admisión de xestión é independente das regras para o tráfico reenviado. Unha ACL que deixa os clientes chegar a servidores detrás da ASA non habilita por si soa a administración SSH do dispositivo, e arranxar a regra de reenvío non moverá este fallo.

management-access é específica da interface

A orde management-access indica á ASA que acepte conexións de xestión nunha interface concreta cando chegan pola VPN. Non crea unha ruta, non engade un permiso SSH e non se aplica a todas as interfaces á vez. Se a interface de destino non é a indicada, a conexión descártase antes da autenticación.

Aquí morden dúas exclusións. As interfaces só de xestión quedan fóra deste mecanismo, e a guía de xestión de ASA 9.20 sinala que a pila CiscoSSH predeterminada non admite SSH entre interfaces pola VPN, mentres que a pila ASA SSH si o fai. Confirme a pila activa na versión despregada antes de dedicar tempo ás rutas.

Catro portas antes do aviso de inicio de sesión

Entre o cliente e o aviso de nome de usuario hai catro portas independentes: unha coincidencia de ruta e túnel para o par de xestión, unha ACL de interface que permite TCP 22 cara ao enderezo da ASA, un permiso ssh que cobre a orixe do administrador e unha autenticación AAA para ese usuario. Cada unha pode descartar o paquete sen dicir ao cliente que porta se pechou.

Use packet-tracer para ver que porta falla antes de cambiar nada: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. O rastro nomea a ACL, a etapa NAT e a decisión to-the-box, o que adoita abondar para separar un problema de encamiñamento dun problema de admisión.

Escriba o permiso estreito, non o amplo

Limite o permiso á subrede administrativa aprobada e á interface que recibe o tráfico do túnel: ssh 10.10.5.0 255.255.255.0 inside. Emparelládeo cun método de autenticación como aaa authentication ssh console LOCAL e unha conta local con nome, en lugar de abrir todas as orixes na interface externa.

Manteña coherentes a ACL de interface e o permiso ssh. Un permiso para unha subrede que a ACL bloquea segue fallando, e unha ACL que permite a subrede sen unha entrada ssh correspondente falla na porta seguinte. Ambas as afirmacións describen o mesmo camiño desde capas distintas, así que revíseas xuntas na configuración en execución.

Verifique desde o host nomeado e volva estreitar

Abra unha sesión nova desde o host de xestión nomeado en lugar de desde a súa mesa, e confirme na ASA que enderezo de orixe e que interface usou a conexión. Revise as sesións activas e a sección SSH da configuración en execución mentres a sesión está aberta, logo péchea e elimine calquera permiso temporal que engadise para as probas. Se a sesión aparece pero cae xusto despois do inicio de sesión, o problema restante é a autorización e non a accesibilidade. Rexistre a interface e a orixe no rexistro de cambios para que a seguinte persoa non repita o diagnóstico.

Manteña a consola ou outra ruta de recuperación aprobada de forma independente dispoñible durante todo o cambio. Cando a ruta privada funcione, confirme que as fontes públicas e os usuarios de VPN non relacionados non obtiveron o mesmo acceso, porque un camiño de xestión que funciona para todos é un problema distinto do que vostede comezou.