O túnel dividido não isenta um host público das regras NAT do ASA

Uma rota split-include arrasta um host público para dentro do túnel, onde o ASA precisa fazer hairpin e traduzir a origem. Se pular qualquer um dos dois passos, o fluxo cai.

O túnel dividido costuma ser descrito como uma forma de manter o tráfego corporativo dentro do túnel e o resto da internet fora do firewall. As duas metades dessa descrição estão erradas do mesmo jeito. O túnel dividido é uma decisão de rota tomada pelo cliente, e uma decisão de rota não diz nada sobre o que acontece com o pacote depois que ele chega ao headend.

Um único serviço de parceiro em um endereço público, que insiste em ver o endereço da sua matriz, basta para derrubar a história.

O mito: o túnel dividido tira o firewall do caminho

A crença é que qualquer destino fora das faixas privadas fica na conexão local de internet, então o firewall nunca o vê e nunca precisa de uma regra para ele. Isso só vale enquanto o destino não estiver na lista do túnel. No momento em que um operador adiciona um host público à ACL split-include, o cliente envia esse tráfego para dentro do túnel, e o ASA precisa rotear, filtrar e traduzir como qualquer outro fluxo descriptografado. No cliente, nada mudou além da lista de destinos.

O cliente não virou um roteador. Ele seguiu a política que você entregou.

O que uma rota split-include realmente faz

Em uma instalação de acesso remoto Cisco ASA, a política de grupo carrega split-tunnel-policy tunnelspecified e uma split-tunnel-network-list que nomeia uma ACL padrão. Cada linha permit dessa ACL é um destino que o cliente deve enviar para o túnel, e todo o resto continua usando a rota padrão local.

Adicionar um host é uma única linha, e é a única parte da mudança que o cliente consegue ver: access-list RA-SPLIT standard permit host 203.0.113.20.

Reconecte o cliente depois. A política é trocada no momento da conexão, então uma sessão já estabelecida mantém a lista antiga e faz a mudança parecer que não fez nada.

O pacote chega e sai pela mesma interface

Agora acompanhe o fluxo após a descriptografia. O pacote entrou pela interface externa através do túnel VPN, seu destino é um endereço público, e a tabela de rotas o envia de volta por essa mesma interface externa em direção à internet. O tráfego que entra e sai por uma única interface é descartado a menos que o ASA seja autorizado a permitir, e é isso que same-security-traffic permit intra-interface faz. Sem isso, a conexão falha de um jeito que parece problema de roteamento e não é.

Essa configuração é global. Ela permite hairpinning para todo fluxo que precise, não só para este host do parceiro, então pertence a uma mudança revisada e não a um teste rápido.

Por que um PAT limitado ao destino não é opcional

O endereço de origem no pacote descriptografado continua sendo o endereço VPN do cliente, normalmente de um pool como 10.77.0.0/24. Esse endereço não tem rota na internet pública, então o parceiro ou nunca responde ou responde para lugar nenhum.

A tradução corrige a origem e deixa o destino intacto. Como os objetos já estão definidos em outro lugar, uma regra manual limitada a este destino tem esta forma:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

A parte destination static importa. Se você a omitir, a regra vira uma tradução ampla que pode casar com muito mais tráfego do que o pretendido, e uma regra identity ampla anterior na ordem pode vencê-la por completo. Verifique show nat detail e a ordem das seções antes de supor que a sua regra é a que casa.

O PAT de interface também significa que o parceiro vê o endereço da interface do ASA, que pode ser traduzido de novo mais acima. Se o contrato nomeia um endereço, confirme de ponta a ponta em vez de em um único salto.

Prove com o destino de teste correto

Use o próprio host do parceiro, não uma página genérica de what-is-my-ip. Essa página quase certamente está fora da lista split, então informa o seu endereço local de internet e não diz nada sobre este caminho. Abra uma conexão nova com o serviço do parceiro e pergunte qual origem eles observaram, ou execute packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed e leia as etapas de NAT e roteamento linha por linha. Um traceroute a partir do cliente é uma verificação mais fraca, porque mostra o caminho que já aconteceu e não a política que o escolheu.

Depois verifique o que não deve mudar. Um site comum ainda precisa sair pela conexão local, e um recurso privado na lista do túnel ainda precisa estar acessível. Uma mudança que conserta o parceiro e quebra qualquer uma dessas duas coisas é outro bug.

A versão que funciona deste desenho é curta: um host na ACL split, permissão de hairpin, uma regra PAT limitada ao destino. Todo o resto da história é o mito.

Artigos relacionados