ASA hairpin: saída a internet ou tramo de VPN entre sedes?

Dous usuarios de acceso remoto detrás do mesmo ASA poden enviar tráfico pola mesma interface exterior e recibir un trato completamente distinto. Un vai a un sitio web público, así que o paquete necesita tradución de orixe e unha ruta de internet. O outro vai a un servidor detrás dun túnel entre sedes que tamén remata nesa interface, así que o paquete necesita identidade, un selector de túnel coincidente e un camiño de volta ao grupo de clientes. O permiso para a mesma interface é un requisito previo para ambos e unha solución para ningún.

Dous tramos, unha interface

Decida que tramo está construíndo antes de escribir unha regra NAT, porque as regras non son intercambiables. O tramo A é de cliente a internet: entra o enderezo do grupo, sae o enderezo público traducido e volve pola mesma interface. O tramo B é de cliente a un prefixo privado no outro lado doutro peer IPsec: o enderezo do grupo consérvase, volve cifrarse e entrégase a un peer que debe saber como responder ao grupo.

O que ambos necesitan primeiro é o permiso para a mesma interface. Sen el, o ASA négase a reenviar un paquete pola interface pola que chegou, e o fallo parece un problema de encamiñamento en lugar dun problema de política:

same-security-traffic permit intra-interface

Esa única liña autoriza un esquema de reenvío, como describe a referencia de NAT do ASA para camiños pola mesma interface. Non engade unha ruta de cliente, non autoriza un recurso, non traduce un enderezo nin negocia un selector IPsec, así que espere engadir tres ou catro cousas máis despois e non lea a súa aceptación como un avance.

Tramo A: o cliente quere internet

Para unha saída a internet, o enderezo do grupo ten que deixar de ser privado antes de que o paquete saia do equipo. Nun deseño PAT corrente, a regra traduce o grupo ao enderezo da interface exterior, e o estado de volta restaura o fluxo cara ao 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

Despois confirme que o cliente pediu realmente ao ASA transportar ese tráfico. Unha exclusión do túnel dividido envía o destino público pola conexión propia do teléfono, que nunca chega ao ASA, e ningunha regra NAT arranxa un paquete que nunca se enviou. Compare a lista de túnel dividido da política de grupo co destino que está a probar.

O resto do tramo é corrente: unha ruta por defecto ou específica utilizábel desde a interface exterior, unha política de acceso que permita o fluxo e DNS xestionado segundo a política de resolución que escollese. Engada route-lookup aquí polo mesmo motivo que máis abaixo, xa que a interface de entrada e a de saída son idénticas.

Tramo B: o cliente quere unha sede privada

Este tramo falla en máis sitios, así que escríbao en orde. Primeiro a ruta do cliente: o prefixo de destino debe estar na lista de túnel dividido, ou o cliente non o porá no túnel. Segundo o selector de túnel: a ACL criptográfica entre sedes debe cubrir o enderezo do grupo cara ao prefixo remoto, non só a LAN local cara ao prefixo remoto. Terceiro a identidade, para que o enderezo do grupo non se traduza ao PAT de internet ao pasar.

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

O lado remoto é a parte que a xente esquece probar. O peer necesita unha ruta de volta ao grupo e un selector que o inclúa, e a súa propia política debe permitir os enderezos de orixe que verá. Se a sede se usa cunha vista traducida, é un deseño válido, pero entón ambos os peers, ambos os selectores e ambas as táboas de encamiñamento teñen que coincidir nos enderezos traducidos.

Revise tamén a orde das regras. Unha regra PAT ampla por riba da regra de identidade traducirá o intercambio privado antes de que a regra de identidade se avalíe, e o síntoma é un túnel de sede sen SA coincidente en lugar dun erro de NAT.

A proba que lle di que tramo construíu

Use a avaliación de ruta do propio ASA en lugar de ler a configuración e confiar na sorte. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed mostra a decisión de NAT, a ruta e o resultado da ACL para un fluxo; repítao cun destino privado. Se a fase NAT reescribe un fluxo de privado a privado, construíu o tramo A para un paquete que necesitaba o tramo B.

Dous comandos máis pechan a fenda. show nat detail imprime a orde de regras que seguiu packet-tracer, e show crypto ipsec sa mostra se existe un selector para o par que espera. Un SA ausente é un problema de configuración do selector ou do peer, non algo que a regra NAT poida reparar.

Verifique cada tramo co tráfico que serve

Acepte o tramo A cunha petición pública corrente do cliente e o tramo B cunha petición a un recurso privado que exista de verdade. Logo repita cada un cun recurso denegado, porque «permitido» e «autorizado pola política de acceso» non son a mesma evidencia, e un ping orixinado no concentrador non exercita ningún dos dous camiños do cliente.

Manteña os dous rexistros de proba separados no tícket: enderezo de orixe, destino, regra NAT que coincidiu e resultado. Cando o seguinte informe diga «a VPN está rota», ese par dille nun minuto que tramo retrocedeu, e a resposta adoita ser unha ruta ou un selector en lugar da liña da mesma interface que todos sospeitan primeiro.