ASA-identiteits-NAT teenoor IOS-NAT-uitsluiting vir VPN-verkeer

'n Tak hou internet-PAT en 'n werf-tot-werf-VPN op dieselfde Cisco-poort, en die VPN hou op werk sodra NAT bygevoeg word. Die adresse binne die tonnel pas nie meer by wat die crypto-ACL beskerm nie, of die eweknie sien vertaalde adresse waarvoor hy geen roete het nie. Cisco los dit op twee plekke: die ASA kies 'n NAT-reel wat 'n adres na homself vertaal, terwyl IOS die vloei deur 'n ACL-weiering buite 'n vertaalreel hou. Albei behou die oorspronklike adresse, en nie een is 'n omseiling van NAT-verwerking nie.

Teken eers die vloei aan voordat jy 'n reel kies

Begin deur die vloei neer te skryf wat jy wil beskerm: die plaaslike LAN-bron, die afgeleë bestemming en die presiese adrespaar wat die IPsec-beleid beskerm. Doen dit voordat jy 'n reel wysig, want die tuple wys watter klassifiseerder of NAT-reel moes gepas het.

Soek dan die reel wat werklik gepas het, nie die een wat jy bedoel het nie. Op albei platforms word NAT in 'n bepaalde volgorde geëvalueer, en 'n vroeëre reel kan wen voordat jou uitsondering ondersoek word. 'n Uitsondering wat korrek lyk maar teen 'n ander reel verloor, lewer nooit die verwagte pakkie aan die beskermingsbeleid nie. Die simptoom lyk soos 'n ontbrekende uitsondering, daarom moet jy eers die reelvolgorde lees.

ASA-identiteits-NAT is 'n reel, nie 'n omseiling nie

Op die ASA is identiteits-NAT 'n NAT-reel waarvan die vertaalde adres gelyk is aan die oorspronklike. Dit word soos enige ander reel gekies en dit installeer steeds 'n vertaalinskrywing, so die pakkie slaan nie NAT-verwerking oor nie. Wat verander, is dat die adresse op die draad dieselfde bly, en dit is wat die IPsec-beleid nodig het.

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

Die reel se koppelvlakke en sy route-lookup-instelling moet by die aanstuurontwerp pas. 'n Reel wat die adres korrek vertaal maar op die verkeerde koppelvlakpaar toegepas word, word nie vir jou vloei gekies nie. Route-lookup bepaal of die vertaalde pakkie gerouteer word of die oorspronklike bestemming gebruik word, en dit bepaal of terugverkeer deur die tonnel kom.

Bestuurstoegang tot die ASA self is 'n aparte geval. As jy identiteits-NAT vir bestuursverkeer gebruik, geld die vrystelling-spesifieke route-lookup-vereiste, en 'n breë uitsondering wat uit 'n VPN-voorbeeld gekopieer is, sal SSH nie regmaak nie.

'n IOS-NAT-ACL-weiering beteken nie hier gekies nie

Op IOS word internet-NAT deur 'n bronlys gedryf, en daardie ACL is 'n klassifiseerder, nie 'n filter nie. 'n Permit-reel kies verkeer vir vertaling; 'n weier-reel beteken die pakkie word hier nie gekies nie. Daardie weiering is nie 'n opdrag om die pakkie te laat val soos 'n weiering in 'n koppelvlak-ACL nie.

Nie hier gekies nie is ook smaller as nooit oral vertaal nie. 'n Ander NAT-reel, 'n ander koppelvlak of 'n route-map kan die vloei steeds vertaal, so die hele NAT-tabel moet gelees word. Die pakkie het steeds 'n roete, 'n pasende crypto-ACL en toestemming by die werklike toegangsbeheer-grense nodig.

'n Minimale IOS-reeling plaas die weiering bo die permit in dieselfde lys en wys die overload-reel na daardie lys. Die crypto-ACL beskerm dan dieselfde paar wat die weiering van vertaling uitsluit.

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

Een toetsbare vraag vir albei modelle

Albei modelle antwoord dieselfde vraag: watter reel het hierdie vloei gepas, en watter adresse het die koppelvlak verlaat? Vang op die buitekoppelvlak en vergelyk die bronadres voor en ná die poort. Kyk dan na die eweknie se siening van die tonnel, want die SA kan op wees terwyl die beskermde vloei elders vertaal word.

Op die ASA wys jy nat detail en die vertaaltabel; op IOS wys jy ip nat translations en die ooreenstemmende ACL-tellers. 'n Reel wat nooit toeneem nie, is nooit gekies nie, en dit wys na volgorde, koppelvlak of rigting eerder as na die crypto-konfigurasie.

Waar die konfigurasie gewoonlik verkeerd loop

Die algemene foute is meganies. Die weiering sit onder die permit en pas nooit nie. Die klassifiseerder word in die verkeerde rigting toegepas, so die terugvloei word vertaal. Die identiteitsreel dek die regte adresse maar die verkeerde koppelvlakpaar. Die crypto-ACL beskerm 'n subnet wat nie meer pas by wat die NAT-reel aanbied nie.

Teken die oorspronklike en aangebode adrespaar langs die reel-eienaar aan, sodat die volgende ingenieur kan sien waarom 'n klassifiseerder vertaling weier terwyl die firewall die toepassing toelaat. Hou dit by die veranderingsticket, nie in 'n persoonlike nota nie. Laat die vloei dan weer loop ná enige NAT-verandering, want reelvolgorde is deel van die konfigurasie selfs wanneer die teks van die reel onveranderd is. 'n Tonnel wat opkom is nie bewys dat die adresse oorleef het nie; net die opgevangde pakkie en die eweknie se gedekapsuleerde siening is dit.