ASA VPN hairpin: enrutar dos túneles por una sola interfaz

Un usuario remoto se conecta al ASA, pide un host detrás de una sucursal, y el ASA envía esa petición por la misma interfaz por la que llegó el usuario. Nada de eso requiere un segundo puerto físico. Lo que sí requiere son cuatro decisiones independientes que la gente tiende a fundir en una: permiso para hacer hairpin, un túnel que proteja las direcciones correctas, una política NAT que conserve el origen que prometiste y una política de acceso que autorice el servicio.

Un paquete, dos túneles

Sigue el flujo y el orden de las operaciones deja de ser misterioso. El paquete llega dentro del túnel de acceso remoto, se descifra y se convierte en un paquete IP corriente con origen en el grupo de clientes. Después el ASA lo enruta, lo compara con la ACL de criptografía de sitio a sitio, lo cifra de nuevo y lo envía por la interfaz exterior hacia la sucursal.

Las direcciones de abajo son ilustrativas, pero la forma importa: el origen es el grupo, no la LAN interna del 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

De ahí se siguen dos cosas. El cliente necesita una ruta para el prefijo de la sucursal a través de su conexión de acceso remoto, lo que significa que el split-tunnel o la lista de rutas empujadas debe incluirla. Y la sucursal debe saber cómo devolver el tráfico a 10.77.0.20 o a la dirección que haya sustituido tu diseño de NAT.

El permiso de hairpin es global

El comando al que la gente recurre es same-security-traffic permit intra-interface. Permite que el tráfico entre y salga por la misma interfaz, que es justo lo que necesita este camino. También es un ajuste global: activarlo cambia el comportamiento de otros flujos que casualmente atraviesan la misma interfaz dos veces.

Por eso pertenece a un registro de cambios y no a una sesión de depuración. Pregunta qué más en el equipo podría ahora tomar un camino por la misma interfaz, y si algo de eso debería. En un borde ocupado con redes de invitados o túneles de socios solapados, la respuesta no es automáticamente no. Escribe el motivo junto al ajuste, porque el siguiente ingeniero encontrará el comando y no la conversación.

El alcance de protección y el NAT son separados

El túnel de sitio a sitio protege lo que seleccione su ACL de criptografía. Si esa ACL nombra la subred interna del ASA como origen, el grupo de acceso remoto no queda protegido y el paquete se descartará o se enviará en claro, según el comportamiento de la plataforma con el tráfico no coincidente. Añade el grupo al flujo protegido cuando el diseño conserve las direcciones del grupo.

Luego el NAT decide si la dirección del grupo sobrevive. El Identity NAT la conserva, y la sucursal ve 10.77.0.20 como origen. La traducción cambia el contrato: la sucursal ahora devuelve el tráfico a la dirección traducida, y su propia política tiene que aceptarlo. El orden de las reglas decide si la ACL de criptografía coincide antes o después de la traducción, así que lee el flujo efectivo en lugar de suponer cuál gana.

No borres las reglas PAT generales de internet para que funcione un solo caso de tránsito. Una exención dirigida o una regla de identidad deliberada son más fáciles de explicar y de revertir que un agujero en la política de salida.

El cifrado no es autorización

Un túnel que funciona solo demuestra que dos extremos coinciden en claves y selectores. No dice nada sobre si este usuario puede alcanzar ese servicio. El filtro VPN o la política de grupo asociados a la conexión de acceso remoto todavía tienen que permitir el destino y el puerto de la sucursal, y la ACL de interfaz del camino exterior sigue aplicándose.

Prueba la respuesta en ambos sentidos. Una conexión que tiene éxito mientras un servicio vecino debería fallar es más informativa que un ping correcto, porque muestra que la política es selectiva y no está abierta de par en par. Si la prueba que debería denegarse tiene éxito, el culpable no es el túnel, sino la política. Guarda ambos resultados en el registro de cambios para que la siguiente persona sepa qué comportamiento era el previsto.

Hairpin o una segunda interfaz

El tránsito hairpin mantiene el diseño pequeño y cuesta un ajuste global. Una interfaz separada, o un túnel basado en rutas con su propia interfaz virtual, aísla el camino de tránsito y te da política por interfaz, a cambio de direccionamiento y otro mapa de criptografía o perfil. Ninguno es más correcto; fallan de forma distinta.

Los diseños basados en rutas son otra disposición, no una casilla en la misma configuración. Si pasas a uno, la discusión sobre la ACL de criptografía basada en políticas deja de aplicarse y la tabla de enrutamiento empieza a hacer el trabajo de selección.

Verifica desde el cliente real

Una sonda originada en el ASA tiene una dirección de origen distinta y no recorrerá el camino del grupo a la sucursal. Usa packet-tracer para comprobar la quíntuple, y luego abre una conexión real desde el cliente remoto real, porque el rastreador simula y no sustituye el enrutamiento ni la política del propio cliente.

Tras un cambio planificado, conéctate a un servicio que debería funcionar, luego a uno que debería ser denegado, y después confirma la ruta de retorno de la sucursal. Los los ejemplos de NAT hairpin para VPN de Cisco mantienen el permiso intra-interface, el NAT y las ACL visiblemente separados, y ese es el modelo mental que merece la pena copiar.