Split-tonnel onthef nie ’n openbare gasheer van die ASA se NAT-reëls nie

Split-tonnel word gewoonlik beskryf as ’n manier om korporatiewe verkeer binne die tonnel te hou en die res van die internet buite die firewall. Albei helftes van daardie beskrywing is op dieselfde manier verkeerd. Split-tonnel is ’n roetebesluit wat die kliënt neem, en ’n roetebesluit sê niks oor wat met die pakkie gebeur nadat dit die hoofkant bereik het nie.

Een vennootdiens op ’n openbare adres wat daarop aandring om jou hoofkwartier se adres te sien, is genoeg om die verhaal te breek.

Die mite: split-tonnel hou die firewall uit die pad

Die oortuiging is dat enige bestemming buite die private reekse op die plaaslike internetverbinding bly, sodat die firewall dit nooit sien nie en nooit ’n reël daarvoor nodig het nie. Dit geld net terwyl die bestemming afwesig is uit die tonnelys. Sodra ’n operateur ’n openbare gasheer by die split-insluit-ACL voeg, stuur die kliënt daardie verkeer in die tonnel in, en die ASA moet dit routeer, filtreer en vertaal soos enige ander ontsyferde vloei. Niks het op die kliënt verander behalwe die bestemmingslys nie.

Die kliënt het nie ’n router geword nie. Dit het die beleid gevolg wat jy vir hom gegee het.

Wat ’n split-insluit-roete werklik doen

Op ’n Cisco ASA-afstandtoegang-opstelling dra die groepsbeleid split-tunnel-policy tunnelspecified en ’n split-tunnel-network-list wat ’n standaard-ACL noem. Elke permit-reël in daardie ACL is ’n bestemming wat die kliënt in die tonnel moet stuur, en alles anders bly die plaaslike verstekroete gebruik.

Om een gasheer by te voeg is ’n enkele reël, en dit is die enigste deel van die verandering wat die kliënt kan sien: access-list RA-SPLIT standard permit host 203.0.113.20.

Herverbind die kliënt daarna. Die beleid word by verbindingstyd uitgeruil, so ’n gevestigde sessie behou die ou lys en laat die verandering lyk asof dit niks gedoen het nie.

Die pakkie kom in en gaan uit op dieselfde koppelvlak

Volg nou die vloei ná ontsyfering. Die pakkie het deur die VPN-tonnel op die buitekoppelvlak ingekom, sy bestemming is ’n openbare adres, en die roetertabel stuur dit weer deur dieselfde buitekoppelvlak na die internet. Verkeer wat by een koppelvlak ingaan en dit verlaat, word laat vaar tensy die ASA toegelaat word om dit toe te laat, en dit is wat same-security-traffic permit intra-interface doen. Sonder dit misluk die verbinding op ’n manier wat soos ’n roeteprobleem lyk en nie een is nie.

Daardie instelling is globaal. Dit laat hairpinning toe vir elke vloei wat dit nodig het, nie net vir hierdie vennootgasheer nie, so dit hoort in ’n nagegane verandering eerder as in ’n vinnige toets.

Waarom ’n bestemmingsgerigte PAT nie opsioneel is nie

Die bronadres op die ontsyferde pakkie is steeds die kliënt se VPN-adres, tipies uit ’n poel soos 10.77.0.0/24. Daardie adres het geen roete op die openbare internet nie, so die vennoot antwoord óf nooit óf antwoord in die niet.

Vertaling regstel die bron en laat die bestemming onaangeraak. Met die objekte wat elders reeds gedefinieer is, het ’n handmatige reël wat op hierdie bestemming gerig is, hierdie vorm:

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

Die destination static-deel is belangrik. As jy dit weglaat, word die reël ’n breë vertaling wat baie meer verkeer kan pas as wat bedoel is, en ’n breë identity-reël vroeër in die volgorde kan hierdie een heeltemal klop. Kontroleer show nat detail en die afdelingvolgorde voordat jy aanneem jou reël is die een wat pas.

Koppelvlak-PAT beteken ook die vennoot sien die ASA se koppelvlakadres, wat verder stroomop weer vertaal kan word. As die kontrak ’n adres noem, bevestig dit van punt tot punt eerder as by een sprong.

Bewys dit met die regte toetsbestemming

Gebruik die vennootgasheer self, nie ’n generiese what-is-my-ip-bladsy nie. Daardie bladsy is byna seker buite die split-lys, so dit rapporteer jou plaaslike internetadres en sê niks oor hierdie pad nie. Maak ’n nuwe verbinding na die vennootdiens oop en vra watter bron hulle waargeneem het, of voer packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed uit en lees die NAT- en roetefases reël vir reël. ’n Traceroute vanaf die kliënt is ’n swakker kontrole, want dit wys die pad wat reeds gebeur het eerder as die beleid wat dit gekies het.

Kontroleer dan wat nie moet verander nie. ’n Gewone webwerf moet steeds vanaf die plaaslike verbinding vertrek, en ’n private hulpbron in die tonnelys moet steeds bereikbaar wees. ’n Verandering wat die vennoot regmaak en een van daardie twee breek, is ’n ander fout.

Die werkende weergawe van hierdie ontwerp is kort: een gasheer in die split-ACL, hairpin-toestemming, een bestemmingsgerigte PAT-reël. Alles anders in die verhaal is die mite.