ASA VPN hairpin: encaminhar dois túneis por uma única interface

Um usuário remoto conecta-se ao ASA, pede um host atrás de uma filial, e o ASA envia esse pedido pela mesma interface por onde o usuário chegou. Nada disso exige uma segunda porta física. O que exige são quatro decisões independentes que as pessoas tendem a fundir numa só: permissão para fazer hairpin, um túnel que proteja os endereços corretos, uma política de NAT que preserve a origem que você prometeu e uma política de acesso que autorize o serviço.

Um pacote, dois túneis

Acompanhe o fluxo e a ordem das operações deixa de ser misteriosa. O pacote chega dentro do túnel de acesso remoto, é descriptografado e torna-se um pacote IP comum com origem no pool de clientes. O ASA então o encaminha, compara-o com a ACL de criptografia de site para site, criptografa-o novamente e envia-o pela interface externa em direção à filial.

Os endereços abaixo são ilustrativos, mas a forma importa: a origem é o pool, não a LAN interna do ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Duas coisas decorrem disso. O cliente precisa de uma rota para o prefixo da filial através da sua conexão de acesso remoto, o que significa que o split-tunnel ou a lista de rotas empurrada deve incluí-la. E a filial precisa de saber como devolver o tráfego para 10.77.0.20 ou para o endereço que o seu desenho de NAT tenha substituído.

A permissão de hairpin é global

O comando a que as pessoas recorrem é same-security-traffic permit intra-interface. Ele permite que o tráfego entre e saia pela mesma interface, que é exatamente o que este caminho precisa. É também uma configuração global: ativá-la altera o comportamento de outros fluxos que atravessam acidentalmente a mesma interface duas vezes.

É por isso que pertence a um registo de alterações e não a uma sessão de depuração. Pergunte o que mais no equipamento poderá agora seguir um caminho pela mesma interface, e se algo disso o deveria fazer. Numa borda movimentada com redes de convidados ou túneis de parceiros sobrepostos, a resposta não é automaticamente não. Escreva o motivo junto à configuração, porque o próximo engenheiro encontrará o comando e não a conversa.

O escopo da proteção e o NAT são separados

O túnel de site para site protege o que a sua ACL de criptografia selecionar. Se essa ACL nomear a sub-rede interna do ASA como origem, o pool de acesso remoto não está protegido e o pacote será descartado ou enviado em claro, conforme o comportamento da plataforma para tráfego não correspondente. Adicione o pool ao fluxo protegido quando o desenho preservar os endereços do pool.

Depois o NAT decide se o endereço do pool sobrevive. O Identity NAT mantém-no, e a filial vê 10.77.0.20 como origem. A tradução altera o contrato: a filial devolve agora o tráfego para o endereço traduzido, e a sua própria política tem de o aceitar. A ordem das regras determina se a ACL de criptografia corresponde antes ou depois da tradução, por isso leia o fluxo efetivo em vez de presumir qual vence.

Não apague as regras PAT gerais da internet para que um único caso de trânsito funcione. Uma exceção dirigida ou uma regra de identidade deliberada são mais fáceis de explicar e de reverter do que um buraco na política de saída.

A criptografia não é autorização

Um túnel a funcionar prova apenas que dois pares concordam em chaves e seletores. Não diz nada sobre se este usuário pode alcançar aquele serviço. O filtro VPN ou a política de grupo ligados à conexão de acesso remoto têm ainda de permitir o destino e a porta da filial, e a ACL da interface no caminho externo continua a aplicar-se.

Teste a resposta nos dois sentidos. Uma ligação que tem sucesso enquanto um serviço vizinho deveria falhar é mais informativa do que um único ping bem-sucedido, porque mostra que a política é seletiva e não está escancarada. Se o teste que deveria ser negado tiver sucesso, o culpado não é o túnel, mas a política. Guarde ambos os resultados no registo de alterações para que a próxima pessoa saiba qual comportamento era o pretendido.

Hairpin ou uma segunda interface

O trânsito hairpin mantém o desenho pequeno e custa uma configuração global. Uma interface separada, ou um túnel baseado em rotas com a sua própria interface virtual, isola o caminho de trânsito e dá-lhe política por interface, ao custo de endereçamento e de mais um crypto map ou perfil. Nenhum é mais correto; falham de forma diferente.

Os desenhos baseados em rotas são outra disposição, não uma caixa de seleção na mesma configuração. Se passar para um deles, a discussão acima sobre a ACL de criptografia baseada em políticas deixa de se aplicar e a tabela de rotas começa a fazer o trabalho de seleção.

Verifique a partir do cliente real

Uma sonda iniciada no ASA tem um endereço de origem diferente e não percorrerá o caminho do pool para a filial. Use packet-tracer para verificar o quintuplo, e depois abra uma ligação real a partir do cliente remoto efetivo, porque o rastreador simula e não substitui o encaminhamento e a política do próprio cliente.

Após uma alteração planeada, ligue-se a um serviço que deveria funcionar, depois a um que deveria ser negado, e em seguida confirme a rota de retorno da filial. Os os exemplos de NAT hairpin para VPN da Cisco mantêm a permissão intra-interface, o NAT e as ACLs visivelmente separados, e esse é o modelo mental que vale a pena copiar.