ASA identity NAT laban sa IOS NAT exemption para sa trapikong VPN

Ang isang sangay ay nagpapatakbo ng internet PAT at site-to-site VPN sa iisang Cisco gateway, at humihinto ang VPN sa sandaling idagdag ang NAT. Hindi na tumutugma ang mga address sa loob ng tunnel sa pinoprotektahan ng crypto ACL, o nakikita ng peer ang mga isinaling address na wala siyang ruta. Nilulutas ito ng Cisco sa dalawang lugar: pumipili ang ASA ng NAT rule na nagmamapa ng address sa sarili nito, habang pinapanatili ng IOS ang flow sa labas ng translation rule sa pamamagitan ng deny sa ACL. Pinapanatili ng dalawa ang orihinal na address, at wala sa kanila ang paglalaktaw sa pagproseso ng NAT.

Itala ang flow bago pumili ng patakaran

Magsimula sa pagsulat ng flow na inaasahan mong protektahan: ang LAN source, ang malayong destinasyon at ang eksaktong pares ng address na pinoprotektahan ng IPsec policy. Gawin ito bago i-edit ang isang patakaran, dahil ipinapakita ng tuple kung aling classifier o NAT rule ang dapat tumugma.

Pagkatapos hanapin ang patakarang aktwal na tumugma, hindi ang sinadya mo. Sa dalawang platform, sinusuri ang NAT sa isang pagkakasunod-sunod, at maaaring manalo ang naunang patakaran bago isaalang-alang ang iyong exemption. Ang exemption na mukhang tama ngunit natatalo sa ibang patakaran ay hindi kailanman naghahatid ng inaasahang packet sa patakaran ng proteksyon. Kapareho ang sintomas ng nawawalang exemption, kaya dapat basahin ang pagkakasunod-sunod ng patakaran bago baguhin ang configuration.

Ang ASA identity NAT ay patakaran, hindi paglalaktaw

Sa ASA, ang identity NAT ay NAT rule na ang isinaling address ay katumbas ng orihinal. Pinipili ito tulad ng anumang patakaran at naglalagay pa rin ng translation entry, kaya hindi nilalaktawan ng packet ang pagproseso ng NAT. Ang nagbabago ay nananatiling pareho ang mga address sa network, at iyon ang kailangan ng IPsec policy.

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

Dapat tumugma ang mga interface ng patakaran at ang setting nitong route-lookup sa disenyo ng pagpapasa. Ang patakarang nagmamapa ng address nang tama ngunit inilalapat sa maling pares ng interface ay hindi pipiliin para sa iyong flow. Ang route-lookup ang nagpapasya kung iruruta ang isinaling packet o gagamitin ang orihinal na destinasyon, at iyon ang nagpapasya kung babalik ang return traffic sa tunnel.

Ang management access sa ASA mismo ay hiwalay na kaso. Kung gumagamit ka ng identity NAT para sa management traffic, nalalapat ang route-lookup requirement na depende sa release, at ang malawak na exemption na kinopya mula sa halimbawa ng VPN ay hindi aayos ng SSH.

Ang deny sa IOS NAT ACL ay nangangahulugang hindi pinili dito

Sa IOS, ang internet NAT ay pinapatakbo ng source list, at ang ACL na iyon ay classifier, hindi filter. Pinipili ng permit line ang traffic para sa pagsasalin; ang deny line ay nangangahulugang hindi pinili ang packet dito. Ang deny na iyon ay hindi utos na itapon ang packet tulad ng deny sa interface ACL.

Ang hindi pinili dito ay mas makitid din kaysa hindi kailanman isasalin kahit saan. Maaari pa ring isalin ng ibang NAT rule, ibang interface o route-map ang flow, kaya dapat basahin ang buong NAT table. Kailangan pa rin ng packet ng ruta, tugmang crypto ACL at pahintulot sa aktwal na hangganan ng access control.

Ang minimal na ayos sa IOS ay naglalagay ng deny sa itaas ng permit sa parehong listahan at itinuturo ang overload rule sa listahang iyon. Pagkatapos ay pinoprotektahan ng crypto ACL ang parehong pares na ibinubukod ng deny sa pagsasalin.

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

Isang nasusubok na tanong para sa dalawang modelo

Parehong sumasagot ang dalawang modelo sa iisang tanong: aling patakaran ang tumugma sa flow na ito, at aling mga address ang umalis sa interface? Kumuha ng capture sa panlabas na interface at ihambing ang source address bago at pagkatapos ng gateway. Pagkatapos tingnan ang pananaw ng peer sa tunnel, dahil maaaring nakataas ang SA habang isinasalin ang protektadong flow sa ibang lugar.

Sa ASA ipakita ang nat detail at ang translation table; sa IOS ipakita ang ip nat translations at ang tugmang ACL counters. Ang patakarang hindi kailanman lumalaki ay hindi kailanman napili, at iyon ay tumutukoy sa pagkakasunod-sunod, interface o direksyon at hindi sa crypto configuration.

Saan karaniwang nagkakamali ang configuration

Ang karaniwang pagkabigo ay mekanikal. Nasa ilalim ng permit ang deny at hindi kailanman tumutugma. Inilalapat ang classifier sa maling direksyon, kaya isinasalin ang return flow. Sinasaklaw ng identity rule ang tamang address ngunit maling pares ng interface. Pinoprotektahan ng crypto ACL ang subnet na hindi na tumutugma sa ipinapakita ng NAT rule.

Itala ang orihinal at ipinakitang pares ng address sa tabi ng may-ari ng patakaran, upang makita ng susunod na inhinyero kung bakit tinatanggihan ng classifier ang pagsasalin habang pinapayagan ng firewall ang application. Itago iyon sa change ticket, hindi sa personal na tala. Pagkatapos ay patakbuhin muli ang flow pagkatapos ng anumang pagbabago sa NAT, dahil bahagi ng configuration ang pagkakasunod-sunod ng patakaran kahit hindi nagbabago ang teksto nito. Ang tunnel na bumabangon ay hindi patunay na nakaligtas ang mga address; tanging ang nakuhang packet at ang decapsulated na pananaw ng peer.