ASA hairpin: ¿salida a internet o tramo de VPN entre sedes?

Dos usuarios de acceso remoto detrás del mismo ASA pueden enviar tráfico por la misma interfaz exterior y recibir un trato completamente distinto. Uno va a un sitio web público, así que el paquete necesita traducción de origen y una ruta de internet. El otro va a un servidor detrás de un túnel entre sedes que también termina en esa interfaz, así que el paquete necesita identidad, un selector de túnel coincidente y un camino de vuelta al grupo de clientes. El permiso para la misma interfaz es un requisito previo para ambos y una solución para ninguno.

Dos tramos, una interfaz

Decida qué tramo está construyendo antes de escribir una regla NAT, porque las reglas no son intercambiables. El tramo A es de cliente a internet: entra la dirección del grupo, sale la dirección pública traducida y vuelve por la misma interfaz. El tramo B es de cliente a un prefijo privado al otro lado de otro peer IPsec: la dirección del grupo se conserva, se vuelve a cifrar y se entrega a un peer que debe saber cómo responder al grupo.

Lo que ambos necesitan primero es el permiso para la misma interfaz. Sin él, el ASA se niega a reenviar un paquete por la interfaz por la que llegó, y el fallo parece un problema de enrutamiento en lugar de un problema de política:

same-security-traffic permit intra-interface

Esa única línea autoriza un esquema de reenvío, como describe la referencia de NAT del ASA para caminos por la misma interfaz. No añade una ruta de cliente, no autoriza un recurso, no traduce una dirección ni negocia un selector IPsec, así que espere añadir tres o cuatro cosas más después y no lea su aceptación como un avance.

Tramo A: el cliente quiere internet

Para una salida a internet, la dirección del grupo tiene que dejar de ser privada antes de que el paquete salga del equipo. En un diseño PAT corriente, la regla traduce el grupo a la dirección de la interfaz exterior, y el estado de vuelta restaura el flujo hacia el 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

Después confirme que el cliente pidió realmente al ASA transportar ese tráfico. Una exclusión del túnel dividido envía el destino público por la conexión propia del teléfono, que nunca llega al ASA, y ninguna regla NAT arregla un paquete que nunca se envió. Compare la lista de túnel dividido de la política de grupo con el destino que está probando.

El resto del tramo es corriente: una ruta por defecto o específica utilizable desde la interfaz exterior, una política de acceso que permita el flujo y DNS gestionado según la política de resolución que haya elegido. Añada route-lookup aquí por la misma razón que más abajo, ya que la interfaz de entrada y la de salida son idénticas.

Tramo B: el cliente quiere una sede privada

Este tramo falla en más sitios, así que escríbalo en orden. Primero la ruta del cliente: el prefijo de destino debe estar en la lista de túnel dividido, o el cliente no lo pondrá en el túnel. Segundo el selector de túnel: la ACL criptográfica entre sedes debe cubrir la dirección del grupo hacia el prefijo remoto, no solo la LAN local hacia el prefijo remoto. Tercero la identidad, para que la dirección del grupo no se traduzca al PAT de internet al pasar.

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

El lado remoto es la parte que la gente olvida probar. El peer necesita una ruta de vuelta al grupo y un selector que lo incluya, y su propia política debe permitir las direcciones de origen que verá. Si la sede se usa con una vista traducida, es un diseño válido, pero entonces ambos peers, ambos selectores y ambas tablas de enrutamiento tienen que coincidir en las direcciones traducidas.

Revise también el orden de las reglas. Una regla PAT amplia por encima de la regla de identidad traducirá el intercambio privado antes de que la regla de identidad se evalúe, y el síntoma es un túnel de sede sin SA coincidente en lugar de un error de NAT.

La prueba que le dice qué tramo construyó

Use la evaluación de ruta del propio ASA en lugar de leer la configuración y confiar en la suerte. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed muestra la decisión de NAT, la ruta y el resultado de la ACL para un flujo; repítalo con un destino privado. Si la fase NAT reescribe un flujo de privado a privado, construyó el tramo A para un paquete que necesitaba el tramo B.

Dos comandos más cierran la brecha. show nat detail imprime el orden de reglas que siguió packet-tracer, y show crypto ipsec sa muestra si existe un selector para el par que espera. Un SA ausente es un problema de configuración del selector o del peer, no algo que la regla NAT pueda reparar.

Verifique cada tramo con el tráfico que sirve

Acepte el tramo A con una petición pública corriente del cliente y el tramo B con una petición a un recurso privado que exista de verdad. Luego repita cada uno con un recurso denegado, porque «permitido» y «autorizado por la política de acceso» no son la misma evidencia, y un ping originado en el concentrador no ejercita ninguno de los dos caminos del cliente.

Mantenga los dos registros de prueba separados en el ticket: dirección de origen, destino, regla NAT que coincidió y resultado. Cuando el siguiente informe diga «la VPN está rota», ese par le dice en un minuto qué tramo ha retrocedido, y la respuesta suele ser una ruta o un selector en lugar de la línea de la misma interfaz que todos sospechan primero.