APRENDER. PRATICAR. EVOLUIR.1. Separar os estados da ligação
Uma ligação fictícia entre um centro de processamento e um parceiro suporta relatórios de fecho. O dashboard mostra IKE estabelecida, mas o ficheiro não chega. Isso não é uma contradição: a associação IKE suporta negociação e controlo, enquanto as Child SAs protegem o tráfego selecionado. O RFC permite que uma IKE SA exista quando a primeira Child SA falha por motivos como seletores não aceitáveis. Antes de alterar parâmetros, regista peer, identidade, versão, momento, etapa e resultado. Não uses “VPN up” como sinónimo de serviço entregue. A aceitação exige também tráfego representativo, retorno, política aplicável e confirmação do resultado pela aplicação.
2. Interpretar a etapa e o erro
A ficha apresenta três pistas independentes. NO_PROPOSAL_CHOSEN durante IKE_SA_INIT pede comparação das propostas IKE; o mesmo tipo de erro durante criação de Child SA dirige a análise para essa proposta. TS_UNACCEPTABLE aponta para o âmbito dos seletores, não prova uma password errada. AUTHENTICATION_FAILED pede revisão da identidade e do método de autenticação, sem divulgar a chave no ticket. Para certificados, inclui validade, cadeia e relógio observado. Uma proposta comum deve continuar dentro da política aprovada. Não acrescentes algoritmos antigos em bloco para obter qualquer ligação verde. Conserva a etapa e o contexto, porque o texto do erro sozinho pode não identificar o componente.
3. Seguir o tráfego protegido
Na ficha, A protege 10.60.10.0/24 para 10.70.20.0/24, mas B só aceita a origem 10.60.10.0/25. O host .30 está dentro de ambos; .200 não está na metade aceite por B. A diferença deve ser reconciliada com o âmbito autorizado, sem alargar tudo a qualquer origem. Considera ainda tradução NAT e ordem das regras efetivas. Uma route-based VPN exige encaminhamento para a VTI e política de acesso adequada; criar a interface não cria uma rota funcional por magia. Compara contadores antes e depois de uma tentativa delimitada em ambos os peers. Cifrar sem receber resposta pode ter causas remotas, de retorno ou aplicação, e não demonstra por si uma chave errada.
4. Validar mudança e continuidade
A configuração guardada no gestor pode estar pendente de deployment. Confirma a revisão efetiva e os dois lados antes de medir o resultado. Numa VTI de reserva, o rótulo backup não decide sozinho o caminho: o encaminhamento participa na escolha. O ensaio de continuidade deve medir transações, reconvergência e capacidade após a falha autorizada, e não apenas o reaparecimento de uma SA. Uma quebra periódica pede correlação com rekey, expiração, encaminhamento e logs dos dois peers; não se conclui rekey só porque a periodicidade parece conveniente. Define condição de rollback e um contacto do parceiro que possa executar e confirmar ações no equipamento sob a sua gestão.
5. Entregar diagnóstico útil a RUN
O handover inclui fluxos permitidos, seletores, rotas, identidade, responsáveis, alarmes e evidência de testes positivos e negativos. Captura apenas o necessário para a investigação e trata credenciais como segredos. Os debugs podem consumir CPU significativa; estabelece janela, âmbito, duração, critério de interrupção e confirmação de desativação. O guia geral de eventos recomenda evitar duplicação entre início e fim quando possível, enquanto o capítulo de diagnóstico VPN pede ambos para a sua vista. Essa diferença exige uma decisão contextual e controlo de volume. A ficha é um exercício de mesa, sem túnel Cisco executado. Resumo: separa controlo, dados e serviço; avança pela evidência que discrimina a próxima hipótese.
O host 10.60.10.30 pertence a /25; 10.60.10.200 não. IKE ativa não resolve a diferença de seletores nem prova entrega do relatório.
Armadilhas comuns
Estado IKE como aceitação da aplicação; trocar chaves perante qualquer erro; ampliar seletores sem autorização; debug ilimitado.
Tópicos relacionados: IPsec e IKEv2 · Routing e NAT · Gestão de mudanças
Um diagnóstico de VPN precisa de etapa, fluxo, sentido e resultado observado.
Referência: Site-to-Site VPN · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security