El túnel dividido no exime a un host público de las reglas NAT del ASA

El túnel dividido se describe normalmente como una forma de mantener el tráfico corporativo dentro del túnel y el resto de Internet fuera del cortafuegos. Las dos mitades de esa descripción son erróneas del mismo modo. El túnel dividido es una decisión de ruta que toma el cliente, y una decisión de ruta no dice nada sobre lo que le ocurre al paquete después de llegar al headend.

Un solo servicio de un socio en una dirección pública, que insiste en ver la dirección de tu sede, basta para desmontar el relato.

El mito: el túnel dividido saca el cortafuegos del camino

La creencia es que cualquier destino fuera de los rangos privados se queda en la conexión local a Internet, así que el cortafuegos nunca lo ve y nunca necesita una regla para él. Eso solo se cumple mientras el destino no esté en la lista del túnel. En el momento en que un operador añade un host público a la ACL split-include, el cliente envía ese tráfico al túnel, y el ASA tiene que enrutarlo, filtrarlo y traducirlo como cualquier otro flujo descifrado. En el cliente no ha cambiado nada salvo la lista de destinos.

El cliente no se convirtió en un router. Siguió la política que le entregaste.

Qué hace realmente una ruta split-include

En una instalación de acceso remoto de Cisco ASA, la política de grupo lleva split-tunnel-policy tunnelspecified y una split-tunnel-network-list que nombra una ACL estándar. Cada línea permit de esa ACL es un destino que el cliente debe enviar al túnel, y todo lo demás sigue usando la ruta predeterminada local.

Añadir un host es una sola línea, y es la única parte del cambio que el cliente puede ver: access-list RA-SPLIT standard permit host 203.0.113.20.

Reconecta el cliente después. La política se intercambia al conectar, así que una sesión establecida conserva la lista antigua y hace que el cambio parezca no haber hecho nada.

El paquete llega y sale por la misma interfaz

Ahora sigue el flujo después del descifrado. El paquete entró por la interfaz exterior a través del túnel VPN, su destino es una dirección pública, y la tabla de enrutamiento lo envía de vuelta por esa misma interfaz exterior hacia Internet. El tráfico que entra y sale por una sola interfaz se descarta a menos que se le permita al ASA, y eso es lo que hace same-security-traffic permit intra-interface. Sin ello, la conexión falla de una forma que parece un problema de enrutamiento y no lo es.

Ese ajuste es global. Permite el hairpinning para cada flujo que lo necesite, no solo para este host del socio, así que pertenece a un cambio revisado y no a una prueba rápida.

Por qué un PAT limitado al destino no es opcional

La dirección de origen del paquete descifrado sigue siendo la dirección VPN del cliente, normalmente de un pool como 10.77.0.0/24. Esa dirección no tiene ruta en la Internet pública, así que el socio o nunca responde o responde a ninguna parte.

La traducción corrige el origen y deja el destino intacto. Como los objetos ya están definidos en otro sitio, una regla manual limitada a este destino tiene 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

La parte destination static importa. Si la quitas, la regla se convierte en una traducción amplia que puede coincidir con mucho más tráfico del previsto, y una regla identity amplia anterior en el orden puede superar esta por completo. Comprueba show nat detail y el orden de las secciones antes de suponer que tu regla es la que coincide.

El PAT de interfaz también significa que el socio ve la dirección de la interfaz del ASA, que puede volver a traducirse más arriba. Si el contrato nombra una dirección, confírmala de extremo a extremo en lugar de en un solo salto.

Demuéstralo con el destino de prueba correcto

Usa el propio host del socio, no una página genérica de what-is-my-ip. Esa página casi con seguridad está fuera de la lista split, así que informa de tu dirección local de Internet y no dice nada sobre este camino. Abre una conexión nueva al servicio del socio y pregúntales qué origen observaron, o ejecuta packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed y lee las etapas de NAT y enrutamiento línea por línea. Un traceroute desde el cliente es una comprobación más débil, porque muestra el camino que ya ocurrió y no la política que lo eligió.

Después comprueba qué no debe cambiar. Un sitio web normal debe seguir saliendo por la conexión local, y un recurso privado de la lista del túnel debe seguir siendo accesible. Un cambio que arregla al socio y rompe cualquiera de esas dos cosas es otro error.

La versión que funciona de este diseño es corta: un host en la ACL split, permiso de hairpin, una regla PAT limitada al destino. Todo lo demás del relato es el mito.