Identity NAT në ASA kundrejt përjashtimit NAT në IOS për trafikun VPN

Një degë mban PAT internet dhe VPN nga sajti në sajt në të njëjtën portë Cisco, dhe VPN ndalon së funksionuari në momentin që shtohet NAT. Adresat brenda tunelit nuk përputhen më me atë që mbron crypto ACL, ose pala tjetër sheh adresa të përkthyera për të cilat nuk ka rrugë. Cisco e zgjidh këtë në dy vende: ASA zgjedh një rregull NAT që pasqyron adresën në vetvete, ndërsa IOS e mban rrjedhën jashtë një rregulli përkthimi përmes një deny në ACL. Të dyja ruajnë adresat origjinale, dhe asnjëra nuk është anashkalim i përpunimit NAT.

Regjistroni rrjedhën përpara se të zgjidhni një rregull

Filloni duke shkruar rrjedhën që prisni të mbroni: burimi i LAN-it, destinacioni i largët dhe çifti i saktë i adresave që mbron politika IPsec. Bëjeni këtë përpara se të redaktoni një rregull, sepse tuple-i tregon cili klasifikues ose rregull NAT duhej të përputhej.

Pastaj gjeni rregullin që u përputh në të vërtetë, jo atë që kishit ndërmend. Në të dyja platformat NAT vlerësohet sipas një rendi, dhe një rregull i mëparshëm mund të fitojë përpara se të merret parasysh përjashtimi juaj. Një përjashtim që duket i saktë por humbet ndaj një rregulli tjetër nuk e dorëzon kurrë paketën e pritur politikës së mbrojtjes. Simptoma është identike me mungesën e përjashtimit, prandaj rendi i rregullave duhet lexuar përpara se të ndryshohet konfigurimi.

Identity NAT në ASA është rregull, jo anashkalim

Në ASA, identity NAT është një rregull NAT adresa e përkthyer e të cilit është e barabartë me origjinalin. Zgjidhet si çdo rregull tjetër dhe ende instalon një zë përkthimi, prandaj paketa nuk e kalon përpunimin NAT. Ajo që ndryshon është se adresat në rrjet mbeten të njëjtat, dhe kjo është ajo që i duhet politikës IPsec.

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

Ndërfaqet e rregullit dhe cilësimi route-lookup duhet të përputhen me dizajnin e përcjelljes. Një rregull që e pasqyron adresën saktë por zbatohet në çiftin e gabuar të ndërfaqeve nuk do të zgjidhet për rrjedhën tuaj. Route-lookup vendos nëse paketa e përkthyer rrugëtohet apo përdoret destinacioni origjinal, dhe kjo përcakton nëse trafiku i kthimit kthehet përmes tunelit.

Qasja administrative në vetë ASA është rast i veçantë. Nëse përdorni identity NAT për trafikun administrativ, zbatohet kërkesa route-lookup e varur nga versioni, dhe një përjashtim i gjerë i kopjuar nga një shembull VPN nuk e rregullon SSH.

Një deny në ACL NAT të IOS do të thotë nuk është zgjedhur këtu

Në IOS, NAT internet drejtohet nga një listë burimesh, dhe ajo ACL është klasifikues, jo filtër. Rreshti permit zgjedh trafikun për përkthim; rreshti deny do të thotë që paketa nuk është zgjedhur këtu. Ai deny nuk është urdhër për ta hedhur paketën siç është një deny në një ACL ndërfaqeje.

Nuk është zgjedhur këtu është gjithashtu më i ngushtë sesa nuk përkthehet askund. Një rregull tjetër NAT, një ndërfaqe tjetër ose një route-map mund ta përkthejnë ende rrjedhën, prandaj duhet lexuar e gjithë tabela NAT. Paketës i duhet ende një rrugë, një crypto ACL që përputhet dhe leje në kufijtë realë të kontrollit të qasjes.

Një rregullim minimal në IOS e vendos deny mbi permit në të njëjtën listë dhe e drejton rregullin overload në atë listë. Atëherë crypto ACL mbron të njëjtin çift që deny përjashton nga përkthimi.

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

Një pyetje e testueshme për të dy modelet

Të dy modelet përgjigjen të njëjtën pyetje: cili rregull u përputh me këtë rrjedhë dhe cilat adresa lanë ndërfaqen? Kapni në ndërfaqen e jashtme dhe krahasoni adresën e burimit përpara dhe pas portës. Pastaj kontrolloni këndvështrimin e palës tjetër për tunelin, sepse SA mund të jetë lart ndërsa rrjedha e mbrojtur përkthehet diku tjetër.

Në ASA shfaqni nat detail dhe tabelën e përkthimeve; në IOS shfaqni ip nat translations dhe numëruesit përkatës të ACL. Një rregull që nuk rritet kurrë nuk është zgjedhur kurrë, dhe kjo tregon rendin, ndërfaqen ose drejtimin, jo konfigurimin crypto.

Ku konfigurimi zakonisht gabon

Dështimet e zakonshme janë mekanike. Deny qëndron nën permit dhe nuk përputhet kurrë. Klasifikuesi zbatohet në drejtimin e gabuar, kështu që rrjedha e kthimit përkthehet. Rregulli identity mbulon adresat e sakta por çiftin e gabuar të ndërfaqeve. Crypto ACL mbron një nënrrjet që nuk përputhet më me atë që paraqet rregulli NAT.

Regjistroni çiftin e adresave origjinale dhe të paraqitura pranë pronarit të rregullit, që inxhinieri i ardhshëm të shohë pse një klasifikues refuzon përkthimin ndërsa firewalli lejon aplikacionin. Mbajeni atë në biletën e ndryshimit, jo në një shënim personal. Pastaj ekzekutoni përsëri rrjedhën pas çdo ndryshimi NAT, sepse rendi i rregullave është pjesë e konfigurimit edhe kur teksti i rregullit nuk ndryshon. Një tunel që ngrihet nuk është provë që adresat mbijetuan; vetëm paketa e kapur dhe pamja e dekapsuluar e palës tjetër.