El túnel dividit no eximeix un host públic de les regles NAT de l’ASA

El túnel dividit se sol descriure com una manera de mantenir el trànsit corporatiu dins del túnel i la resta d’Internet fora del tallafoc. Les dues meitats d’aquesta descripció són incorrectes de la mateixa manera. El túnel dividit és una decisió d’encaminament que pren el client, i una decisió d’encaminament no diu res sobre què passa amb el paquet després d’arribar al headend.

Un sol servei de soci en una adreça pública, que insisteix a veure l’adreça de la teva seu, ja n’hi ha prou per fer caure aquest relat.

El mite: el túnel dividit treu el tallafoc del camí

La creença és que qualsevol destinació fora dels rangs privats es queda a la connexió local a Internet, de manera que el tallafoc no la veu mai i no necessita cap regla per a ella. Això només es compleix mentre la destinació no és a la llista del túnel. En el moment que un operador afegeix un host públic a l’ACL split-include, el client envia aquest trànsit dins del túnel, i l’ASA l’ha d’encaminar, filtrar i traduir com qualsevol altre flux desxifrat. Al client no ha canviat res excepte la llista de destinacions.

El client no s’ha convertit en un encaminador. Ha seguit la política que li has donat.

Què fa realment una ruta split-include

En una instal·lació d’accés remot de Cisco ASA, la política de grup porta split-tunnel-policy tunnelspecified i una split-tunnel-network-list que anomena una ACL estàndard. Cada línia permit d’aquesta ACL és una destinació que el client ha d’enviar al túnel, i tota la resta continua fent servir la ruta per defecte local.

Afegir un host és una sola línia, i és l’única part del canvi que el client pot veure: access-list RA-SPLIT standard permit host 203.0.113.20.

Torna a connectar el client després. La política s’intercanvia en el moment de la connexió, així que una sessió establerta conserva la llista antiga i fa que el canvi sembli que no ha fet res.

El paquet arriba i surt per la mateixa interfície

Ara segueix el flux després del desxifratge. El paquet ha entrat per la interfície exterior a través del túnel VPN, la seva destinació és una adreça pública, i la taula d’encaminament el torna a enviar per aquesta mateixa interfície exterior cap a Internet. El trànsit que entra i surt per una sola interfície es descarta tret que es digui a l’ASA que ho permeti, i això és el que fa same-security-traffic permit intra-interface. Sense això, la connexió falla d’una manera que sembla un problema d’encaminament i no ho és.

Aquest paràmetre és global. Permet el hairpinning per a cada flux que el necessiti, no només per a aquest host de soci, així que pertany a un canvi revisat i no a una prova ràpida.

Per què un PAT limitat a la destinació no és opcional

L’adreça d’origen del paquet desxifrat continua sent l’adreça VPN del client, normalment d’un pool com 10.77.0.0/24. Aquesta adreça no té ruta a Internet pública, així que el soci o bé no respon mai o bé respon enlloc.

La traducció corregeix la font i deixa la destinació intacta. Com que els objectes ja estan definits en un altre lloc, una regla manual limitada a aquesta destinació té aquesta 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 part destination static és important. Si la treus, la regla es converteix en una traducció àmplia que pot coincidir amb molt més trànsit del previst, i una regla identity àmplia anterior en l’ordre pot superar aquesta completament. Comprova show nat detail i l’ordre de les seccions abans de suposar que la teva regla és la que coincideix.

El PAT d’interfície també vol dir que el soci veu l’adreça de la interfície de l’ASA, que pot tornar-se a traduir més amunt. Si el contracte nomena una adreça, confirma-la d’extrem a extrem i no en un sol salt.

Demostra-ho amb la destinació de prova correcta

Fes servir el mateix host del soci, no una pàgina genèrica de what-is-my-ip. Aquesta pàgina gairebé segur que és fora de la llista split, així que informa de la teva adreça local d’Internet i no diu res sobre aquest camí. Obre una connexió nova al servei del soci i pregunta’ls quina font han observat, o executa packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed i llegeix les etapes de NAT i d’encaminament línia per línia. Un traceroute des del client és una comprovació més feble, perquè mostra el camí que ja ha passat i no la política que l’ha triat.

Després comprova què no ha de canviar. Un lloc web corrent ha de continuar sortint per la connexió local, i un recurs privat dins de la llista del túnel ha de continuar sent accessible. Un canvi que arregla el soci i trenca qualsevol d’aquestes dues coses és un altre error.

La versió que funciona d’aquest disseny és curta: un host a l’ACL split, permís de hairpin, una regla PAT limitada a la destinació. Tota la resta del relat és el mite.