A split tunnel nem mentesíti a nyilvános hostot az ASA NAT-szabályai alól

A split tunnelinget általában úgy írják le, mint a vállalati forgalom alagúton belül tartásának és az internet többi részének a tűzfalon kívül tartásának módját. Ennek a leírásnak mindkét fele ugyanúgy hibás. A split tunneling az ügyfél által hozott útvonal-döntés, és az útvonal-döntés semmit sem mond arról, mi történik a csomaggal, miután eléri a headendet.

Egyetlen partner-szolgáltatás egy nyilvános címen, amely ragaszkodik ahhoz, hogy lássa a központod címét, elég ahhoz, hogy megbuktassa a történetet.

A mítosz: a split tunnel kiveszi a tűzfalat az útvonalból

A hit az, hogy a privát tartományokon kívüli bármely cél a helyi internetkapcsolaton marad, így a tűzfal soha nem látja, és soha nem kell szabályt alkotni rá. Ez csak addig igaz, amíg a cél nincs benne az alagút listájában. Abban a pillanatban, amikor egy üzemeltető hozzáad egy nyilvános hostot a split-include ACL-hez, az ügyfél beleküldi a forgalmat az alagútba, és az ASA-nak útvonalaznia, szűrnie és fordítania kell, mint bármely más visszafejtett flow-t. Az ügyfélen semmi sem változott a céllistán kívül.

Az ügyfél nem lett router. Azt a házirendet követte, amit adtál neki.

Mit tesz valójában egy split-include útvonal

Egy Cisco ASA távoli hozzáférési beállításban a csoportházirend split-tunnel-policy tunnelspecified-t és egy split-tunnel-network-list-t tartalmaz, amely egy szabványos ACL-t nevez meg. Az ACL minden permit sora egy cél, amelyet az ügyfélnek az alagútba kell küldenie, és minden más továbbra is a helyi alapértelmezett útvonalat használja.

Egy host hozzáadása egyetlen sor, és ez a változás egyetlen része, amelyet az ügyfél lát: access-list RA-SPLIT standard permit host 203.0.113.20.

Utána csatlakoztasd újra az ügyfelet. A házirend a kapcsolódáskor cserélődik, így a már létrejött munkamenet megtartja a régi listát, és a változás úgy tűnik, mintha semmit sem tett volna.

A csomag ugyanazon az interfészen érkezik és távozik

Kövesd most a flow-t a visszafejtés után. A csomag a VPN-alagúton keresztül a külső interfészen érkezett, a célja nyilvános cím, és az útvonaltábla ugyanazon a külső interfészen küldi vissza az internet felé. Az egy interfészen be- és kilépő forgalom eldobásra kerül, hacsak az ASA nem kap engedélyt, és ezt teszi a same-security-traffic permit intra-interface. Enélkül a kapcsolat olyan módon hibázik, amely útvonalproblémának látszik, de nem az.

Ez a beállítás globális. Minden flow számára engedélyezi a hairpinninget, amelynek szüksége van rá, nem csak ennek a partnerhostnak, ezért egy átvizsgált változtatásba tartozik, nem egy gyors teszthez.

Miért nem választható a célhoz kötött PAT

A visszafejtett csomag forráscíme továbbra is az ügyfél VPN-címe, jellemzően egy 10.77.0.0/24-hez hasonló poolból. Ennek a címnek nincs útvonala a nyilvános interneten, ezért a partner vagy soha nem válaszol, vagy a semmibe válaszol.

A fordítás kijavítja a forrást, és érintetlenül hagyja a célt. Mivel az objektumok már máshol definiálva vannak, az erre a célra korlátozott kézi szabály így néz ki:

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 destination static rész számít. Ha kihagyod, a szabály széles fordítássá válik, amely a szándékosnál sokkal több forgalomra illeszkedhet, és egy korábban a sorrendben szereplő széles identity szabály teljesen felülmúlhatja ezt. Ellenőrizd a show nat detail-öt és a szakaszok sorrendjét, mielőtt feltételezed, hogy a te szabályod az illeszkedő.

Az interfész PAT azt is jelenti, hogy a partner az ASA interfészcímét látja, amely fentebb újra fordítható. Ha a szerződés megnevez egy címet, igazold végponttól végpontig, ne egy ugrásnál.

Bizonyítsd a megfelelő tesztcéllal

Magát a partnerhostot használd, ne egy általános what-is-my-ip oldalt. Az az oldal szinte biztosan a split listán kívül van, így a helyi internetcímedet jelenti, és semmit sem mond erről az útvonalról. Nyiss új kapcsolatot a partner szolgáltatásához, és kérdezd meg, milyen forrást láttak, vagy futtasd a packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed-ot, és olvasd végig soronként a NAT és útvonalazási szakaszokat. Az ügyfélről indított traceroute gyengébb ellenőrzés, mert azt az útvonalat mutatja, amely már megtörtént, nem pedig azt a házirendet, amely kiválasztotta.

Utána ellenőrizd, minek nem szabad megváltoznia. Egy közönséges weboldalnak továbbra is a helyi kapcsolatból kell kimennie, és az alagút listáján lévő privát erőforrásnak továbbra is elérhetőnek kell lennie. Az a változtatás, amely megjavítja a partnert és elrontja a kettő valamelyikét, egy másik hiba.

Ennek a tervezésnek a működő változata rövid: egy host a split ACL-ben, hairpin engedély, egy célhoz kötött PAT-szabály. A történet többi része a mítosz.