Recentemente, tive um problema: o cliente possui dois Cisco ASA 5512-x, que operam no modo ativo / em espera. O cliente esqueceu de atualizar as senhas e todos os usuários expiraram a senha. Ao tentar entrar, o ASA relata somente a data de validade e não permite que você altere a senha. Como todos os usuários expiraram, não foi possível conectar e alterar a senha de nenhuma maneira. Sempre houve uma opção irônica de redefinir a senha alterando o registro, mas não há tempo de inatividade aqui. Esta opção não se encaixou. Foi decidido usar o ASA em espera para evitar o tempo de inatividade. Mas havia algumas nuances:
1) Se você apenas reiniciar o ASA em espera, entrar no modo ROMMON, alterar caso e inicialização, obteremos acesso e poderemos alterar senhas, mas assim que executarmos
copy startup-config running-config
o ASA imediatamente à espera encontrará o nó ativo e já sincronizará a configuração de lá.
2) Se você desligar a sincronização e apenas baixar a configuração, o ASA em espera assumirá endereços IP ativos e teremos um conflito.
Após a reflexão, o seguinte plano foi inventado:
1. Reinicialize o ASA em espera, vá para ROMMON, altere o registro para 0x41 e inicialize:
rommon
rommon
2. Agora desconectamos todas as interfaces ASA em espera (é possível no comutador em que o ASA está conectado ou apenas retira todos os cabos de rede do próprio ASA).
3. Entramos no modo EXEC privilegiado:
hostname> enable
e carregue a configuração de trabalho:
hostname# copy startup-config running-config
Aqui o ASA em espera sem interfaces ativas não pode sincronizar dados nem prejudicar conflitos de endereço IP se se considerar um nó ativo. Entramos na configuração e adicionamos um novo usuário para acesso adicional:
hostname# configure terminal hostname(config)# username test password test
4. Aqui você pode fazer as coisas de maneira diferente, não conecte os cabos, apenas no final conecte fisicamente os cabos que desconectamos ou os conectamos, mas antes disso desconecte todas as interfaces da configuração. Nesta fase, foi decidido desativar todas as interfaces através da configuração e preparar a inclusão.
hostname(config)# interface interface_id hostname(config-if)# shutdown
5. Retorne o registro padrão, salve a configuração e reinicie.
hostname(config)# no config-register hostname(config)# write
Agora o ASA em espera após a reinicialização será inicializado com a configuração e o teste do usuário que precisamos. O ASA não poderá encontrar o nó ativo para sincronização no modo de espera, pois as interfaces estão desativadas e a ativação do sistema não arruinará nada pelo mesmo motivo.
6. Agora, depois de carregar com a configuração desejada, podemos conectar-se ao usuário de teste. Estamos conectados e entramos no modo EXEC privilegiado. Em seguida, ative a interface ou interfaces que foram projetadas para failover. Depois disso, nosso ASA em espera encontrará o nó ativo, sincronizará as configurações e mudará para o modo de espera. Nesse caso, nosso teste de usuário será excluído, mas como nesse momento já estamos no modo EXEC privilegiado, nossa sessão permanecerá. Se partirmos neste momento, não poderemos entrar, por isso devemos ser extremamente cuidadosos aqui. Todas as outras interfaces também serão ativadas devido à sincronização da configuração do nó ativo.
Podemos alterar senhas de usuário apenas no nó ativo, mas ainda não temos acesso a ele. A saída é tornar nosso ASA stanby ativo com nosso acesso existente. Quando nosso ASA em espera entra no estado de prontidão em espera após a sincronização com o nó ativo, podemos fazer uma troca. Você pode visualizar o status usando o comando:
hostname(config)# show failover state
E com o segundo comando, trocamos do ASA ativo para o ASA em espera:
hostname(config)# failover active
7. Agora, estamos com acesso no nó ativo. Aqui já é possível alterar as senhas do usuário e retornar, se necessário (se isso for crítico).
Assim, podemos redefinir senhas sem tempo de inatividade neste esquema. Você só precisa considerar o atraso ao alternar do nó ativo para o de backup.