ASA hairpin: saída para a internet ou perna VPN site a site?

Dois usuários de acesso remoto atrás do mesmo ASA podem enviar tráfego pela mesma interface externa e receber um tratamento completamente diferente. Um vai para um site público, então o pacote precisa de tradução de origem e de uma rota de internet. O outro vai para um servidor atrás de um túnel site a site que também termina nessa interface, então o pacote precisa de identidade, de um seletor de túnel correspondente e de um caminho de volta ao pool de clientes. A permissão para a mesma interface é um pré-requisito para ambos e uma solução para nenhum.

Duas pernas, uma interface

Decida qual perna você está construindo antes de digitar uma regra NAT, porque as regras não são intercambiáveis. A perna A é de cliente para internet: o endereço do pool entra, o endereço público traduzido sai, volta pela mesma interface. A perna B é de cliente para um prefixo privado do outro lado de outro peer IPsec: o endereço do pool é preservado, recriptografado e entregue a um peer que precisa saber como responder ao pool.

O que ambos precisam primeiro é a permissão para a mesma interface. Sem ela o ASA se recusa a encaminhar um pacote pela interface por onde ele chegou, e a falha parece um problema de roteamento em vez de um problema de política:

same-security-traffic permit intra-interface

Essa única linha autoriza um arranjo de encaminhamento, como descreve a referência de NAT do ASA para caminhos pela mesma interface. Ela não adiciona rota de cliente, não autoriza recurso, não traduz endereço nem negocia seletor IPsec, então espere acrescentar mais três ou quatro coisas depois dela e não leia a aceitação como progresso.

Perna A: o cliente quer a internet

Para uma saída para a internet, o endereço do pool precisa deixar de ser privado antes de o pacote sair do equipamento. Num projeto PAT comum, a regra traduz o pool para o endereço da interface externa, e o estado de retorno restaura o fluxo para o cliente:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Depois confirme que o cliente realmente pediu ao ASA para transportar esse tráfego. Uma exclusão do túnel dividido envia o destino público pela conexão do próprio telefone, que nunca chega ao ASA, e nenhuma regra NAT conserta um pacote que nunca foi enviado. Compare a lista de túnel dividido da política de grupo com o destino que você está testando.

O resto da perna é comum: uma rota padrão ou específica utilizável a partir da interface externa, uma política de acesso que permita o fluxo e DNS tratado conforme a política de resolvedor escolhida. Adicione route-lookup aqui pelo mesmo motivo de baixo, já que as interfaces de entrada e de saída são idênticas.

Perna B: o cliente quer um site privado

Esta perna falha em mais lugares, então escreva-a em ordem. Primeiro a rota do cliente: o prefixo de destino precisa estar na lista de túnel dividido, ou o cliente não o colocará no túnel. Segundo o seletor de túnel: a ACL criptográfica site a site precisa cobrir o endereço do pool até o prefixo remoto, não apenas a LAN local até o prefixo remoto. Terceiro a identidade, para que o endereço do pool não seja traduzido para o PAT de internet na passagem.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

O lado remoto é a parte que as pessoas esquecem de testar. O peer precisa de uma rota de volta ao pool e de um seletor que o inclua, e sua própria política precisa permitir os endereços de origem que verá. Se o site for usado por uma visão traduzida, isso é um projeto válido, mas então ambos os peers, ambos os seletores e ambas as tabelas de roteamento precisam concordar sobre os endereços traduzidos.

Verifique também a ordem das regras. Uma regra PAT ampla acima da regra de identidade traduzirá a troca privada antes de a regra de identidade ser avaliada, e o sintoma é um túnel de site sem SA correspondente em vez de um erro de NAT.

O teste que diz qual perna você construiu

Use a avaliação de caminho do próprio ASA em vez de ler a configuração e torcer. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed mostra a decisão de NAT, a rota e o resultado da ACL para um fluxo; repita com um destino privado. Se a fase NAT reescrever um fluxo de privado para privado, você construiu a perna A para um pacote que precisava da perna B.

Mais dois comandos fecham a lacuna. show nat detail imprime a ordem de regras que o packet-tracer seguiu, e show crypto ipsec sa mostra se existe um seletor para o par que você espera. Um SA ausente é uma questão de configuração de seletor ou de peer, não algo que a regra NAT possa consertar.

Verifique cada perna com o tráfego que ela atende

Aceite a perna A com uma requisição pública comum do cliente e a perna B com uma requisição a um recurso privado que realmente exista. Depois repita cada uma com um recurso negado, porque «permitido» e «autorizado pela política de acesso» não são a mesma evidência, e um ping originado no concentrador não exercita nenhum dos dois caminhos do cliente.

Mantenha os dois registros de teste separados no chamado: endereço de origem, destino, regra NAT que coincidiu e resultado. Quando o próximo relatório disser «a VPN está quebrada», esse par diz em um minuto qual perna regrediu, e a resposta costuma ser uma rota ou um seletor em vez da linha da mesma interface que todos suspeitam primeiro.