Cisco ASA para Azure VPN: pares de prefixos do seletor de tráfego

O túnel sobe, o IKE parece saudável e nada o atravessa. Essa é a forma habitual de um problema de seletor de ASA para Azure, e é por isso que escrevo o contrato antes de tocar em qualquer um dos consoles. O contrato são quatro coisas: os objetos que identificam cada peer, o modelo de conexão, os pares de prefixos exatos e a verificação que prova cada par. Erre nisso e cada comando seguinte vai depurar uma configuração que você não deveria ter construído. Este runbook é a ordem que uso, com os comandos que mostram qual objeto está realmente errado.

Anote os quatro objetos antes de configurar

Comece pela versão e plataforma do ASA, pelo endpoint público, pelo tipo e SKU do gateway VPN do Azure e pelo gateway de rede local que representa o seu lado. Esses quatro nomes são o vocabulário de tudo o que vem a seguir, e cada um tem um responsável diferente quando algo quebra.

Se dois deles ainda são suposições, pare. Uma lista de prefixos errada no gateway de rede local não é um problema de ajuste.

Escolha um modelo de conexão e pare de misturar modelos de configuração

Um projeto com crypto map e um projeto com tunnel interface são configurações diferentes, e o modelo de um não se torna válido para o outro editando o endereço do peer. Registre qual você está construindo antes de colar qualquer coisa, porque a divergência aparece depois como problema de seletor e não como erro de configuração. O guia de interoperabilidade do ASA da Microsoft cobre os dois padrões e diz qual modelo de gateway do Azure cada um pressupõe. Se suas notas não nomeiam o modelo, você ainda não tem um projeto.

Um gateway do Azure baseado em rotas com seletores de tráfego baseados em políticas é uma opção específica documentada, não o padrão. Se o seu projeto depende disso, o projeto precisa dizer, porque o modelo padrão de seletor baseado em rotas se comporta de forma diferente no lado do Azure.

Os limites de versão também pertencem ao contrato. Um relatório de campo antigo sobre um limite de domínios de criptografia é um dado sobre versões específicas, não uma propriedade permanente de todo ASA.

Enumere os pares de prefixos, não os agregados

Escreva a matriz. De A e B no local para X e Y no Azure são quatro pares, e cada um precisa de cobertura ou de uma exclusão explícita. Juntar A e B num único agregado também inclui tudo o que está entre eles, e é assim que um projeto cresce silenciosamente um buraco.

Verifique o que os peers negociaram, não o que você salvou. A lista de redes locais e remotas no ASA é intenção; os CHILD SAs são o resultado.

Quando falta um par, a correção costuma ser uma linha de access-list ou uma entrada de seletor, não um novo túnel.

Verifique com comandos que nomeiam o objeto

No ASA confirme a sessão IKE, depois os SAs IPsec, depois os pares de seletor. Cada comando responde a uma pergunta diferente, e executar apenas o primeiro é como «o túnel está de pé» se torna uma conclusão falsa. Leia a saída do peer que você realmente configurou, não do SA que por acaso está primeiro na lista. O lado do Azure responde às mesmas três perguntas do seu próprio ponto de vista.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Depois pergunte ao Azure o estado da conexão com az network vpn-connection show --name <connection> --query connectionStatus. Conectado com zero bytes no caminho de dados é um problema de seletor, não de roteamento.

Teste um fluxo permitido por par, inspecione o endereço de origem visto do outro lado e tente um recurso que deveria ser negado. Só esse último teste prova que a fronteira ainda existe.

Mantenha o escopo de criptografia separado da permissão de acesso

Um seletor amplo não é permissão. Se o layout suportado for mais amplo que a política da aplicação, mantenha os serviços estreitos nas regras de firewall e deixe o escopo de criptografia onde ele precisa estar.

As rotas de carga de trabalho do Azure e as rotas de retorno locais são revisadas separadamente. Anúncios BGP, escopo de rede estático e rotas definidas pelo usuário precisam descrever o mesmo caminho, e nenhum deles pode capturar o transporte do peer recursivamente.

Reversão e a prova de que funcionou

Guarde a configuração em execução anterior antes de mudar os seletores e saiba o único comando que a restaura. No ASA isso significa uma cópia salva e o caminho de restauração correspondente, não a memória do que você editou. Escreva o comando de restauração no ticket de mudança enquanto a mudança ainda é hipotética. Depois execute novamente as mesmas três verificações: estado do IKE, pares de SA IPsec, um fluxo permitido por par.

Se um par ainda falhar após a restauração, a mudança não era a causa, e você acabou de evitar uma segunda indisponibilidade.