ASA:n identiteetti-NAT vastaan IOS:n NAT-poikkeus VPN-liikenteelle

Cisco-yhdyskäytävissä sekä ASA:n identiteetti-NAT että IOS:n NAT-luokittelijan poikkeus säilyttävät VPN-osoitteet. Säännöt eroavat siinä, missä käännös ohitetaan.

Toimipiste pitää internet-PAT:ia ja sivustojen välistä VPN:ää samalla Cisco-yhdyskäytävällä, ja VPN lakkaa toimimasta heti, kun NAT lisätään. Tunnelissa olevat osoitteet eivät enää vastaa sitä, mitä crypto ACL suojaa, tai vastapuoli näkee käännettyjä osoitteita, joille sillä ei ole reittiä. Cisco ratkaisee tämän kahdessa paikassa: ASA valitsee NAT-säännön, joka kuvaa osoitteen itseensä, kun taas IOS pitää virtauksen käännössäännön ulkopuolella ACL:n denyllä. Molemmat säilyttävät alkuperäiset osoitteet, eikä kumpikaan ohita NAT-käsittelyä.

Kirjaa virtaus ennen säännön valintaa

Aloita kirjaamalla virtaus, jonka odotat suojaavan: paikallisen LAN:n lähde, etäkohde ja täsmällinen osoitepari, jota IPsec-käytäntö suojaa. Tee se ennen säännön muokkaamista, koska monikko osoittaa, minkä luokittelijan tai NAT-säännön olisi pitänyt täsmätä.

Etsi sitten sääntö, joka todella täsmäsi, ei se, jonka tarkoitit. Molemmilla alustoilla NAT arvioidaan järjestyksessä, ja aikaisempi sääntö voi voittaa ennen kuin poikkeustasi katsotaan. Oikealta näyttävä poikkeus, joka häviää toiselle säännölle, ei koskaan luovuta odotettua pakettia suojakäytännölle. Oire on sama kuin puuttuvassa poikkeuksessa, siksi sääntöjärjestys on luettava ennen kokoonpanon muuttamista.

ASA:n identiteetti-NAT on sääntö, ei ohitus

ASA:ssa identiteetti-NAT on NAT-sääntö, jonka käännetty osoite on sama kuin alkuperäinen. Se valitaan kuten mikä tahansa muu sääntö ja se asentaa silti käännöksen merkinnän, joten paketti ei ohita NAT-käsittelyä. Muutos on siinä, että osoitteet johdolla pysyvät samoina, ja juuri sitä IPsec-käytäntö tarvitsee.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Säännön liitännät ja sen route-lookup-asetus on sovitettava edelleenlähetyssuunnitelmaan. Sääntö, joka kuvaa osoitteen oikein mutta kohdistetaan väärään liitäntäpariin, ei tule valituksi virtauksellesi. Route-lookup päättää, reititetäänkö käännetty paketti vai käytetäänkö alkuperäistä kohdetta, ja se ratkaisee, palaako paluuliikenne tunnelin kautta.

Hallintayhteys itse ASA:han on erillinen tapaus. Jos käytät identiteetti-NAT:ia hallintaliikenteelle, julkaisuversiokohtainen route-lookup-vaatimus pätee, eikä VPN-esimerkistä kopioitu laaja poikkeus korjaa SSH:ta.

IOS:n NAT-ACL:n deny tarkoittaa ei valittu tässä

IOS:ssa internet-NAT:ia ohjaa lähdeluettelo, ja se ACL on luokittelija, ei suodatin. Permit-rivi valitsee liikenteen käännettäväksi; deny-rivi tarkoittaa, että pakettia ei valita tässä. Se deny ei ole käsky hylätä paketti kuten liitännän ACL:n deny.

Ei valittu tässä on myös kapeampi kuin ei koskaan missään käännetty. Toinen NAT-sääntö, toinen liitäntä tai route-map voi yhä kääntää virtauksen, joten koko NAT-taulu on luettava. Paketti tarvitsee yhä reitin, täsmäävän crypto ACL:n ja luvan todellisilla käyttöoikeuden rajoilla.

Minimaalinen IOS-järjestely sijoittaa denyn permitin yläpuolelle samaan luetteloon ja osoittaa overload-säännön siihen luetteloon. Silloin crypto ACL suojaa saman parin, jonka deny jättää käännöksen ulkopuolelle.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Yksi testattava kysymys molemmille malleille

Molemmat mallit vastaavat samaan kysymykseen: mikä sääntö täsmäsi tähän virtaukseen ja mitkä osoitteet lähtivät liitännästä? Kaappaa ulkoliitännällä ja vertaa lähdeosoitetta ennen yhdyskäytävää ja sen jälkeen. Tarkista sitten vastapuolen näkemys tunnelista, koska SA voi olla pystyssä samalla kun suojattu virtaus käännetään muualla.

ASA:ssa näytä nat detail ja käännöstaulu; IOS:ssa näytä ip nat translations ja vastaavat ACL-laskurit. Sääntö, joka ei koskaan kasva, ei ollut koskaan valittu, ja se viittaa järjestykseen, liitäntään tai suuntaan eikä crypto-kokoonpanoon.

Missä kokoonpano yleensä menee pieleen

Yleiset viat ovat mekaanisia. Deny on permitin alla eikä täsmää koskaan. Luokittelija kohdistetaan väärään suuntaan, joten paluuvirtaus käännetään. Identiteettisääntö kattaa oikeat osoitteet mutta väärän liitäntäparin. Crypto ACL suojaa aliverkkoa, joka ei enää vastaa sitä, mitä NAT-sääntö esittää.

Kirjaa alkuperäinen ja esitetty osoitepari säännön omistajan viereen, jotta seuraava insinööri näkee, miksi luokittelija kieltää käännöksen samalla kun palomuuri sallii sovelluksen. Pidä se muutostiketissä, älä henkilökohtaisessa muistiinpanossa. Aja virtaus sitten uudelleen jokaisen NAT-muutoksen jälkeen, koska sääntöjärjestys on osa kokoonpanoa myös silloin, kun säännön teksti ei muutu. Ylös nouseva tunneli ei todista, että osoitteet säilyivät; vain kaapattu paketti ja vastapuolen purettu näkymä todistavat.

Aiheeseen liittyvät artikkelit