SSH para uma ASA remota através da VPN do site: passo a passo

Aponte um cliente SSH para o endereço interno da ASA remota e a sessão morre na conexão. A firewall responde a partir do seu próprio site, o túnel aparece e, ainda assim, nada escuta na porta 22. Na maioria destes casos o pacote nunca chega à admissão de gestão, porque o caminho testado nunca foi desenhado como caminho de gestão. Siga o fluxo abaixo por ordem e a falha deixa de se deslocar.

Escolha o endereço que está realmente a administrar

Três desenhos parecem iguais e comportam-se de forma diferente: alcançar o endereço público da ASA virado para a VPN, alcançar uma interface interna através de IPsec e alcançar uma interface de gestão dedicada. Anote o endereço de origem do administrador, o endereço exato de destino e TCP 22 antes de tocar em qualquer autorização. Tudo o que vem depois depende desse par.

Um túnel que transporta duas VLAN de servidores pode não transportar de todo o endereço da interface da firewall nem a sub-rede de gestão do administrador. Verifique a lista de tráfego interessante da política de site para site e confirme que o próprio endereço da ASA aparece como destino, não apenas as sub-redes que o atravessam.

Como o destino é a própria firewall, a admissão de gestão é separada das regras para o tráfego encaminhado. Uma ACL que deixa os clientes alcançar servidores atrás da ASA não ativa por si só a administração SSH do equipamento, e corrigir a regra de encaminhamento não desloca esta falha.

management-access é específico da interface

O comando management-access diz à ASA para aceitar ligações de gestão numa interface nomeada quando chegam pela VPN. Não cria uma rota, não acrescenta uma autorização SSH e não se aplica a todas as interfaces ao mesmo tempo. Se a interface de destino não for a nomeada, a ligação é descartada antes da autenticação.

Duas exclusões mordem aqui. As interfaces apenas de gestão ficam fora deste mecanismo, e o guia de gestão da ASA 9.20 nota que a pilha CiscoSSH predefinida não suporta SSH entre interfaces pela VPN, enquanto a pilha ASA SSH suporta. Confirme a pilha ativa na versão implementada antes de gastar tempo com rotas.

Quatro portas antes do pedido de início de sessão

Entre o cliente e o pedido de nome de utilizador estão quatro portas independentes: uma correspondência de rota e túnel para o par de gestão, uma ACL de interface que permite TCP 22 para o endereço da ASA, uma autorização ssh que cobre a origem do administrador e uma autenticação AAA para esse utilizador. Cada uma pode descartar o pacote sem dizer ao cliente qual porta se fechou.

Utilize o packet-tracer para ver que porta falha antes de mudar seja o que for: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. O traço nomeia a ACL, a fase NAT e a decisão to-the-box, o que normalmente basta para separar um problema de encaminhamento de um problema de admissão.

Escreva a autorização estreita, não a ampla

Limite a autorização à sub-rede administrativa aprovada e à interface que recebe o tráfego do túnel: ssh 10.10.5.0 255.255.255.0 inside. Combine-a com um método de autenticação como aaa authentication ssh console LOCAL e uma conta local nomeada, em vez de abrir todas as origens na interface externa.

Mantenha a ACL de interface e a autorização ssh coerentes. Uma autorização para uma sub-rede que a ACL bloqueia continua a falhar, e uma ACL que permite a sub-rede sem uma entrada ssh correspondente falha na porta seguinte. Ambas as afirmações descrevem o mesmo caminho a partir de camadas diferentes, por isso reveja-as em conjunto na configuração em execução.

Verifique a partir do anfitrião nomeado e volte a restringir

Abra uma nova sessão a partir do anfitrião de gestão nomeado em vez de a partir da sua secretária, e confirme na ASA que endereço de origem e que interface utilizou a ligação. Verifique as sessões ativas e a secção SSH da configuração em execução enquanto a sessão está aberta, depois feche-a e remova qualquer autorização temporária que tenha acrescentado para os testes. Se a sessão aparecer mas cair logo após o início de sessão, o problema restante é a autorização e não a acessibilidade. Registe a interface e a origem no registo de alterações para que a pessoa seguinte não repita o diagnóstico.

Mantenha a consola ou outro caminho de recuperação aprovado de forma independente disponível durante toda a alteração. Quando o caminho privado funcionar, confirme que as origens públicas e os utilizadores de VPN não relacionados não obtiveram o mesmo acesso, porque um caminho de gestão que funciona para todos é um problema diferente daquele com que começou.