Como modelar um fluxo VPN com ASA packet-tracer

Packet-tracer num ASA responde a uma pergunta estreita: este pacote, que entra aqui com esta tupla, seria permitido e para onde iria. Não responde se o extremo remoto recebe algo. O erro habitual é fornecer uma tupla IKE externa quando o que quer testar é a aplicação que viaja dentro do túnel. Corrija primeiro a tupla, leia as fases e só depois recolha provas reais de tudo o que o simulador não consegue ver.

O percurso abaixo assume que a ACL, a regra NAT e o contexto tunnel-group estão à sua frente. Sem eles, a saída descreve uma política que não pode verificar.

Passo 1: escreva o fluxo interno em palavras simples

Descreva a aplicação antes de escrever seja o que for. Um anfitrião do interior que abre SSH para um servidor atrás do gateway remoto é um fluxo TCP interno com uma porta de origem específica. É esse o fluxo que a ACL e o filtro VPN avaliam, por isso é esse o fluxo que escreve.

Escreva-o como uma frase e depois traduza campo a campo:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Passo 2: escolha a entrada e a direção

A entrada é a interface por onde o pacote chega, não aquela por onde sai. Para um anfitrião LAN que inicia, é a interface inside. Para o pacote de retorno da mesma sessão, é a interface outside, e a tupla inverte-se. Escrever o destino como origem é a segunda forma mais comum de obter um ALLOW convincente mas irrelevante.

As portas também têm direção. A porta do serviço pertence ao campo de destino num pedido iniciado, e a porta efémera do cliente pertence ao campo de origem. Um modelo com destino TCP 500 descreve uma aplicação TCP à escuta em 500; não se torna um teste IKE só porque o número aparece no comando.

Passo 3: leia as fases por ordem

Cada fase da saída é uma decisão com dono: procura de rota, ACL, NAT e depois seleção de VPN ou túnel. Leia-as pela ordem impressa e pare na primeira fase que discorde do desenho.

O NAT apanha muita gente. Se a origem traduzida cair fora da crypto ACL que seleciona o tráfego para o túnel, o fluxo pode ser permitido e nunca encapsulado. O traço imprime o endereço traduzido, por isso compare-o com o tráfego interessante do túnel e não com o endereço original.

Passo 4: verifique que contornos selecionou

A forma detailed aceita opções que saltam verificações, e a Cisco documenta uma opção bypass-checks que cobre ACL, filtro VPN, uRPF e verificações de falsificação IPsec. Um ALLOW obtido com esses contornos diz que a rota e o NAT funcionariam, não que a política admitiria um pacote real. Registe as opções ao lado do resultado.

Se precisa da resposta de política, execute sem os contornos. Se está a isolar uma questão de encaminhamento, execute com eles e rotule o resultado como resposta de encaminhamento.

Passo 5: feche a lacuna com a troca real

Uma permissão simulada para no ASA. Se o gateway remoto desencriptou o pacote, se o servidor aceitou a ligação e se voltou uma resposta são observações separadas. Use contadores de extremo ou uma captura estreita num caminho aprovado.

Algumas opções de trace e replay transmitem pacotes ou preservam estado. Siga o comportamento documentado para a sua versão e o seu procedimento de diagnóstico aprovado em vez de tratar cada variante como uma consulta só de leitura.

O que o traço ainda não lhe pode dizer

Guarde quatro coisas numa nota: a tupla, a regra NAT correspondente, o túnel ou a política que deveria transportar o fluxo e a observação específica da direção. Sem elas, um engenheiro posterior não consegue separar uma decisão local de política de um plano de controlo estabelecido e de um serviço a funcionar. Uma primeira falha seguida de sucesso também não prova que o túnel tivesse de subir entretanto; registe a fase e a mudança de estado.

Comece pela tupla interior, pare na primeira fase que contradiga o desenho e só então procure provas de extremo. O traço é um oráculo de política, não um recibo de entrega.