ASA-ի identity NAT-ը՝ ընդդեմ IOS-ի NAT բացառության VPN երթևեկության համար

Մասնաճյուղը պահում է ինտերնետ PAT-ը և site-to-site VPN-ը նույն Cisco դարպասի վրա, և VPN-ը դադարում է աշխատել այն պահին, երբ ավելացվում է NAT: Թունելի ներսի հասցեները այլևս չեն համապատասխանում այն ամենին, ինչը պաշտպանում է crypto ACL-ը, կամ հակառակ կողմը տեսնում է թարգմանված հասցեներ, որոնց համար երթուղի չունի: Cisco-ն լուծում է սա երկու տեղում. ASA-ն ընտրում է NAT կանոն, որը հասցեն քարտեզագրում է ինքն իրեն, իսկ IOS-ը ACL-ի deny-ով հոսքը պահում է թարգմանության կանոնից դուրս: Երկուսն էլ պահպանում են սկզբնական հասցեները, և ոչ մեկը NAT մշակման շրջանցում չէ:

Գրանցեք հոսքը կանոն ընտրելուց առաջ

Սկսեք գրել այն հոսքը, որը ակնկալում եք պաշտպանել՝ տեղական LAN աղբյուրը, հեռավոր նպատակակետը և այն ճշգրիտ զույգ հասցեները, որոնք պաշտպանում է IPsec քաղաքականությունը: Արեք դա կանոնը խմբագրելուց առաջ, քանի որ այս բազմությունը ցույց է տալիս, թե որ դասակարգիչը կամ NAT կանոնը պետք է համընկներ:

Այնուհետև գտեք այն կանոնը, որը իրականում համընկել է, ոչ այն, ինչը նկատի ունեիք: Երկու հարթակներում էլ NAT-ը գնահատվում է հերթականությամբ, և ավելի վաղ կանոնը կարող է հաղթել նախքան ձեր բացառությունը դիտարկելը: Ճիշտ թվացող, բայց մեկ այլ կանոնի պարտվող բացառությունը երբեք չի հանձնում սպասվող փաթեթը պաշտպանության քաղաքականությանը: Ախտանիշը նույնն է, ինչ բացակայող բացառության դեպքում, ուստի կանոնների հերթականությունը պետք է կարդալ կարգավորումը փոխելուց առաջ:

ASA-ի identity NAT-ը կանոն է, ոչ շրջանցում

ASA-ում identity NAT-ը NAT կանոն է, որի թարգմանված հասցեն հավասար է սկզբնականին: Այն ընտրվում է ինչպես ցանկացած այլ կանոն և դեռ տեղադրում է թարգմանության գրառում, այնպես որ փաթեթը չի բաց թողնում NAT մշակումը: Փոխվում է այն, որ լարի վրա հասցեները մնում են նույնը, և դա է, ինչ պետք է IPsec քաղաքականությանը:

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

Կանոնի ինտերֆեյսները և դրա route-lookup կարգավորումը պետք է համապատասխանեն փոխանցման նախագծին: Կանոնը, որը հասցեն ճիշտ է քարտեզագրում, բայց կիրառվում է սխալ ինտերֆեյսների զույգի վրա, չի ընտրվի ձեր հոսքի համար: Route-lookup-ը որոշում է՝ թարգմանված փաթեթը երթուղարկվի՞, թե՞ օգտագործվի սկզբնական նպատակակետը, և դա որոշում է՝ վերադարձի երթևեկությունը թունելով հետ կգա՞:

Հենց ASA-ի կառավարման հասանելիությունը առանձին դեպք է: Եթե կառավարման երթևեկության համար օգտագործում եք identity NAT, գործում է թողարկումից կախված route-lookup պահանջը, և VPN օրինակից պատճենված լայն բացառությունը չի ուղղի SSH-ը:

IOS-ի NAT ACL-ի deny-ն նշանակում է՝ այստեղ ընտրված չէ

IOS-ում ինտերնետ NAT-ը ղեկավարվում է աղբյուրների ցանկով, և այդ ACL-ը դասակարգիչ է, ոչ զտիչ: Permit տողը երթևեկությունն ընտրում է թարգմանության համար. deny տողը նշանակում է, որ փաթեթն այստեղ ընտրված չէ: Այդ deny-ն փաթեթը գցելու հրահանգ չէ, ինչպես ինտերֆեյսի ACL-ի deny-ն:

Այստեղ ընտրված չլինելը նաև ավելի նեղ է, քան ոչ մի տեղ չթարգմանվելը: Մեկ այլ NAT կանոն, մեկ այլ ինտերֆեյս կամ route-map դեռ կարող են թարգմանել հոսքը, ուստի պետք է կարդալ ամբողջ NAT աղյուսակը: Փաթեթին դեռ պետք են երթուղի, համապատասխան crypto ACL և թույլտվություն փաստացի հասանելիության վերահսկման սահմաններում:

Նվազագույն IOS դասավորությունը deny-ն դնում է permit-ից վեր նույն ցանկում և overload կանոնը ուղղում է այդ ցանկին: Այն ժամանակ crypto ACL-ը պաշտպանում է նույն զույգը, որը deny-ն բացառում է թարգմանությունից:

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

Մեկ ստուգելի հարց երկու մոդելների համար

Երկու մոդելներն էլ պատասխանում են նույն հարցին՝ ո՞ր կանոնը համընկավ այս հոսքի հետ, և ո՞ր հասցեները լքեցին ինտերֆեյսը: Գրավեք արտաքին ինտերֆեյսի վրա և համեմատեք աղբյուրի հասցեն դարպասից առաջ և հետո: Ապա ստուգեք հակառակ կողմի տեսլականը թունելի վերաբերյալ, քանի որ SA-ն կարող է բարձրացված լինել, մինչ պաշտպանված հոսքը թարգմանվում է այլ տեղ:

ASA-ում ցուցադրեք nat detail-ը և թարգմանությունների աղյուսակը. IOS-ում՝ ip nat translations-ը և համապատասխան ACL հաշվիչները: Կանոնը, որը երբեք չի աճում, երբեք ընտրված չի եղել, և դա մատնանշում է հերթականությունը, ինտերֆեյսը կամ ուղղությունը, ոչ թե crypto կարգավորումը:

Որտեղ է կարգավորումը սովորաբար սխալվում

Տարածված խափանումները մեխանիկական են: deny-ն permit-ից ներքև է և երբեք չի համընկնում: Դասակարգիչը կիրառվում է սխալ ուղղությամբ, ուստի վերադարձի հոսքը թարգմանվում է: identity կանոնը ծածկում է ճիշտ հասցեները, բայց սխալ ինտերֆեյսների զույգը: Crypto ACL-ը պաշտպանում է ենթացանց, որն այլևս չի համապատասխանում NAT կանոնի ներկայացրածին:

Գրանցեք սկզբնական և ներկայացված հասցեների զույգը կանոնի սեփականատիրոջ կողքին, որպեսզի հաջորդ ինժեները տեսնի, թե ինչու դասակարգիչը մերժում է թարգմանությունը, մինչ firewall-ը թույլատրում է հավելվածը: Պահեք դա փոփոխության տոմսում, ոչ անձնական նշումում: Ապա կրկին գործարկեք հոսքը ցանկացած NAT փոփոխությունից հետո, քանի որ կանոնների հերթականությունը կարգավորման մաս է նույնիսկ երբ կանոնի տեքստը չի փոխվել: Բարձրացած թունելը ապացույց չէ, որ հասցեները պահպանվել են. միայն գրավված փաթեթը և հակառակ կողմի ապակապսուլացված տեսքը: