Split-tunneli ei vapauta julkista hostia ASA:n NAT-säännöistä
Split-include-reitti vetää julkisen hostin tunneliin, jossa ASA:n on tehtävä hairpin ja käännettävä lähde. Jätä kumpi tahansa vaihe väliin, niin yhteys katkeaa.
Split-tunneli kuvataan yleensä tavaksi pitää yrityksen liikenne tunnelin sisällä ja muu internet palomuurin ulkopuolella. Kuvauksen molemmat puolet ovat väärin samalla tavalla. Split-tunneli on asiakkaan tekemä reittipäätös, eikä reittipäätös kerro mitään siitä, mitä paketille tapahtuu sen saavuttua headendiin.
Yksi kumppanipalvelu julkisessa osoitteessa, joka vaatii nähdä pääkonttorisi osoitteen, riittää kumoamaan tarinan.
Myytti: split-tunneli poistaa palomuurin reitiltä
Uskomus on, että mikä tahansa yksityisten alueiden ulkopuolinen kohde pysyy paikallisella internet-yhteydellä, joten palomuuri ei näe sitä koskaan eikä tarvitse sille koskaan sääntöä. Tämä pitää vain niin kauan kuin kohde ei ole tunneliluettelossa. Heti kun ylläpitäjä lisää julkisen hostin split-include-ACL:ään, asiakas lähettää liikenteen tunneliin, ja ASA:n on reititettävä, suodatettava ja käännettävä se kuten mikä tahansa muu purettu yhteys. Asiakkaassa ei muuttunut mikään muu kuin kohdeluettelo.
Asiakkaasta ei tullut reititintä. Se noudatti antamaasi käytäntöä.
Mitä split-include-reitti oikeastaan tekee
Cisco ASA:n etäkäyttöasetelmassa ryhmäkäytäntö kantaa split-tunnel-policy tunnelspecified ja split-tunnel-network-list, joka nimeää vakio-ACL:n. Jokainen kyseisen ACL:n permit-rivi on kohde, jonka asiakkaan pitää lähettää tunneliin, ja kaikki muu käyttää edelleen paikallista oletusreittiä.
Yhden hostin lisääminen on yksi rivi, ja se on ainoa osa muutosta, jonka asiakas voi nähdä: access-list RA-SPLIT standard permit host 203.0.113.20.
Yhdistä asiakas sen jälkeen uudelleen. Käytäntö vaihdetaan yhteyden muodostuksen yhteydessä, joten olemassa oleva istunto säilyttää vanhan luettelon ja saa muutoksen näyttämään siltä, ettei se tehnyt mitään.
Paketti saapuu ja lähtee samalta liitännältä
Seuraa nyt yhteyttä purkamisen jälkeen. Paketti saapui ulkoliitännälle VPN-tunnelin kautta, sen kohde on julkinen osoite, ja reititystaulu lähettää sen takaisin saman ulkoliitännän kautta internettiin. Liikenne, joka tulee sisään ja lähtee ulos yhdeltä liitännältä, pudotetaan, ellei ASA:lle ole annettu lupaa sallia sitä, ja juuri sen same-security-traffic permit intra-interface tekee. Ilman sitä yhteys epäonnistuu tavalla, joka näyttää reititysongelmalta mutta ei ole sitä.
Tämä asetus on globaali. Se sallii hairpinningin jokaiselle yhteydelle, joka sitä tarvitsee, ei vain tälle kumppanihostille, joten se kuuluu katselmoituun muutokseen eikä pikakokeeseen.
Miksi kohdekohtainen PAT ei ole valinnainen
Purettavan paketin lähdeosoite on edelleen asiakkaan VPN-osoite, tyypillisesti altaasta kuten 10.77.0.0/24. Sillä osoitteella ei ole reittiä julkisessa internetissä, joten kumppani joko ei vastaa koskaan tai vastaa tyhjyyteen.
Käännös korjaa lähteen ja jättää kohteen koskemattomaksi. Koska objektit on jo määritelty muualla, tähän kohteeseen rajattu käsinsääntö näyttää tältä:
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_HOSTdestination static -osa on tärkeä. Jos sen jättää pois, säännöstä tulee laaja käännös, joka voi osua paljon useampaan liikenteeseen kuin on tarkoitettu, ja aiemmin järjestyksessä oleva laaja identity-sääntö voi voittaa tämän kokonaan. Tarkista show nat detail ja osioiden järjestys ennen kuin oletat sääntösi olevan se, joka osuu.
Liitännän PAT tarkoittaa myös sitä, että kumppani näkee ASA:n liitäntäosoitteen, joka voidaan kääntää vielä uudelleen ylempänä. Jos sopimus nimeää osoitteen, vahvista se päästä päähän eikä yhdellä hypyllä.
Todista se oikealla testikohteella
Käytä kumppanihostia itseään, älä yleistä what-is-my-ip-sivua. Se sivu on lähes varmasti split-luettelon ulkopuolella, joten se raportoi paikallisen internet-osoitteesi eikä kerro tästä polusta mitään. Avaa uusi yhteys kumppanipalveluun ja kysy, mitä lähdettä he näkivät, tai suorita packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed ja lue NAT- ja reititysvaiheet rivi riviltä. Asiakkaasta tehty traceroute on heikompi tarkistus, koska se näyttää polun, joka jo tapahtui, eikä käytäntöä, joka valitsi sen.
Tarkista sitten, mikä ei saa muuttua. Tavallisen verkkosivuston on edelleen lähdettävä paikallisen yhteyden kautta, ja tunneliluettelossa olevan yksityisen resurssin on edelleen oltava tavoitettavissa. Muutos, joka korjaa kumppanin ja rikkoo jommankumman näistä, on toinen vika.
Tämän suunnittelun toimiva versio on lyhyt: yksi host split-ACL:ssä, hairpin-lupa, yksi kohdekohtainen PAT-sääntö. Kaikki muu tarinassa on myytti.