O túnel dividido non exime un host público das regras NAT do ASA

O túnel dividido descríbese habitualmente como unha forma de manter o tráfico corporativo dentro do túnel e o resto de Internet fóra da devasa. As dúas metades desa descrición son erróneas do mesmo xeito. O túnel dividido é unha decisión de ruta que toma o cliente, e unha decisión de ruta non di nada sobre o que lle ocorre ao paquete despois de chegar ao headend.

Un só servizo dun socio nun enderezo público, que insiste en ver o enderezo da túa sede, abonda para derrubar o relato.

O mito: o túnel dividido saca a devasa do camiño

A crenza é que calquera destino fóra dos rangos privados queda na conexión local a Internet, así que a devasa nunca o ve e nunca necesita unha regra para el. Iso só se cumpre mentres o destino non estea na lista do túnel. No momento en que un operador engade un host público á ACL split-include, o cliente envía ese tráfico ao túnel, e o ASA ten que encamiñalo, filtralo e traducilo como calquera outro fluxo descifrado. No cliente non cambiou nada agás a lista de destinos.

O cliente non se converteu nun router. Seguiu a política que lle deches.

Que fai realmente unha ruta split-include

Nunha instalación de acceso remoto de Cisco ASA, a política de grupo leva split-tunnel-policy tunnelspecified e unha split-tunnel-network-list que nomea unha ACL estándar. Cada liña permit desa ACL é un destino que o cliente debe enviar ao túnel, e todo o demais segue usando a ruta predeterminada local.

Engadir un host é unha soa liña, e é a única parte do cambio que o cliente pode ver: access-list RA-SPLIT standard permit host 203.0.113.20.

Reconecta o cliente despois. A política intercámbiase ao conectar, así que unha sesión establecida conserva a lista antiga e fai que o cambio pareza non ter feito nada.

O paquete chega e sae pola mesma interface

Agora segue o fluxo despois do descifrado. O paquete entrou pola interface exterior a través do túnel VPN, o seu destino é un enderezo público, e a táboa de encamiñamento devólveo por esa mesma interface exterior cara a Internet. O tráfico que entra e sae por unha soa interface descártase a menos que se lle permita ao ASA, e iso é o que fai same-security-traffic permit intra-interface. Sen iso, a conexión falla dun xeito que parece un problema de encamiñamento e non o é.

Ese axuste é global. Permite o hairpinning para cada fluxo que o necesite, non só para este host do socio, así que pertence a un cambio revisado e non a unha proba rápida.

Por que un PAT limitado ao destino non é opcional

O enderezo de orixe do paquete descifrado segue sendo o enderezo VPN do cliente, normalmente dun pool como 10.77.0.0/24. Ese enderezo non ten ruta na Internet pública, así que o socio ou nunca responde ou responde a ningures.

A tradución corrixe a orixe e deixa o destino intacto. Como os obxectos xa están definidos noutro sitio, unha regra manual limitada a este destino ten 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

A parte destination static importa. Se a quitas, a regra convértese nunha tradución ampla que pode coincidir con moito máis tráfico do previsto, e unha regra identity ampla anterior na orde pode superar esta por completo. Comproba show nat detail e a orde das seccións antes de supor que a túa regra é a que coincide.

O PAT de interface tamén significa que o socio ve o enderezo da interface do ASA, que pode volver traducirse máis arriba. Se o contrato nomea un enderezo, confírmao de extremo a extremo en lugar de nun só salto.

Demostra con o destino de proba correcto

Usa o propio host do socio, non unha páxina xenérica de what-is-my-ip. Esa páxina está case con seguridade fóra da lista split, así que informa do teu enderezo local de Internet e non di nada sobre este camiño. Abre unha conexión nova ao servizo do socio e pregúntalles que orixe observaron, ou executa packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed e le as etapas de NAT e encamiñamento liña por liña. Un traceroute desde o cliente é unha comprobación máis feble, porque mostra o camiño que xa ocorreu e non a política que o escolleu.

Despois comproba que non debe cambiar. Un sitio web normal debe seguir saíndo pola conexión local, e un recurso privado da lista do túnel debe seguir sendo accesible. Un cambio que arranxa o socio e rompe calquera desas dúas cousas é outro erro.

A versión que funciona deste deseño é curta: un host na ACL split, permiso de hairpin, unha regra PAT limitada ao destino. Todo o demais do relato é o mito.