Ինչպես մոդելավորել VPN հոսքը ASA packet-tracer-ով

Packet-tracer-ը ASA-ի վրա պատասխանում է նեղ հարցի՝ արդյոք այս փաթեթը, որն այստեղ մտնում է այս tuple-ով, կթույլատրվի, և ուր այն կգնա։ Այն չի պատասխանում՝ ստանում է արդյոք հեռավոր ծայրը որևէ բան։ Սովորական սխալը արտաքին IKE tuple մատակարարելն է, երբ փորձարկվողը թունելի ներսում ընթացող հավելվածն է։ Նախ ուղղեք tuple-ը, կարդացեք փուլերը, ապա ստացեք իրական ապացույցներ այն ամենի համար, ինչ սիմուլյատորը չի տեսնում։

Ստորև բերված շրջայցը ենթադրում է, որ ACL-ը, NAT կանոնը և tunnel-group համատեքստը ձեր առջև են։ Առանց դրանց ելքը նկարագրում է քաղաքականություն, որը չեք կարող ստուգել։

Քայլ 1՝ գրեք ներքին հոսքը պարզ բառերով

Նկարագրեք հավելվածը նախքան որևէ բան մուտքագրելը։ Ներսի հոսթը, որը SSH է բացում հեռավոր դարպասի հետևում գտնվող սերվերի նկատմամբ, մեկ ներքին TCP հոսք է՝ որոշակի աղբյուրի պորտով։ Դա այն հոսքն է, որը գնահատում են ACL-ը և VPN զտիչը, ուստի դա այն հոսքն է, որը մուտքագրում եք։

Գրեք այն որպես նախադասություն, ապա թարգմանեք դաշտ առ դաշտ՝

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Քայլ 2՝ ընտրեք մուտքի ինտերֆեյսը և ուղղությունը

Մուտքը այն ինտերֆեյսն է, որին ժամանում է փաթեթը, ոչ այն, որով այն հեռանում է։ Սկսող LAN հոսթի համար դա inside ինտերֆեյսն է։ Նույն սեսիայի վերադարձի փաթեթի համար դա outside ինտերֆեյսն է, և tuple-ը շրջվում է։ Նպատակը որպես աղբյուր գրելը վստահելի, բայց անտեղի ALLOW ստանալու երկրորդ ամենատարածված եղանակն է։

Պորտերը նույնպես ուղղորդված են։ Ծառայության պորտը սկսված հարցման դեպքում պատկանում է նպատակի դաշտին, իսկ հաճախորդի ժամանակավոր պորտը պատկանում է աղբյուրի դաշտին։ TCP նպատակը 500-ով մոդելը նկարագրում է TCP հավելված, որը լսում է 500-ով, և այն չի դառնում IKE փորձարկում միայն այն պատգառով, որ թիվը հայտնվում է հրամանում։

Քայլ 3՝ կարդացեք փուլերը հերթականությամբ

Ելքի յուրաքանչյուր փուլ որոշում է՝ տիրոջով. երթուղու որոնում, ACL, NAT, ապա VPN կամ թունելի ընտրություն։ Կարդացեք դրանք տպված հերթականությամբ և կանգ առեք առաջին այն փուլում, որը չի համապատասխանում նախագծին։

NAT-ը հաճախ շփոթեցնում է մարդկանց։ Եթե թարգմանված աղբյուրը դուրս է մնում թունելի համար երթևեկություն ընտրող crypto ACL-ից, հոսքը կարող է թույլատրվել և երբեք չփաթեթավորվել։ Հետագիծը տպում է թարգմանված հասցեն, ուստի համեմատեք այն թունելի հետաքրքիր երթևեկության հետ, ոչ թե սկզբնական հասցեի։

Քայլ 4՝ ստուգեք, թե որ շրջանցումներն եք ընտրել

detailed ձևը ընդունում է տարբերակներ, որոնք բաց են թողնում ստուգումները, և Cisco-ն փաստաթղթավորում է bypass-checks տարբերակը, որն ընդգրկում է ACL, VPN զտիչ, uRPF և IPsec կեղծման ստուգումներ։ Դրանցով շրջանցված ստացված ALLOW-ը ասում է, որ երթուղին և NAT-ը կաշխատեին, ոչ թե որ քաղաքականությունը կընդունի իրական փաթեթ։ Գրանցեք տարբերակները արդյունքի կողքին։

Եթե ձեզ պետք է քաղաքականության պատասխանը, գործարկեք առանց շրջանցումների։ Եթե մեկուսացնում եք երթուղավորման հարց, գործարկեք դրանցով և արդյունքը պիտակավորեք որպես երթուղավորման պատասխան։

Քայլ 5՝ փակեք բացը իրական փոխանակմամբ

Մոդելավորված թույլտվությունը կանգ է առնում ASA-ում։ Արդյոք հեռավոր դարպասը վերծանել է փաթեթը, արդյոք սերվերը ընդունել է կապը և արդյոք պատասխան է վերադարձել, առանձին դիտարկումներ են։ Օգտագործեք վերջնակետերի հաշվիչներ կամ նեղ գրավում հաստատված ուղու վրա։

Որոշ trace և replay տարբերակներ փոխանցում են փաթեթներ կամ պահպանում վիճակ։ Հետևեք ձեր թողարկման և հաստատված ախտորոշման ընթացակարգի փաստաթղթավորված վարքին՝ փոխարենը յուրաքանչյուր տարբերակ միայն ընթերցման հարցում համարելու։

Ինչ դեռ չի կարող ասել հետագիծը

Մեկ նշումում պահեք չորս բան՝ tuple-ը, համապատասխան NAT կանոնը, թունելը կամ քաղաքականությունը, որը պետք է կրի հոսքը, և ուղղությանը հատուկ դիտարկումը։ Առանց դրանց ավելի ուշ ինժեները չի կարող տարանջատել տեղական քաղաքականության որոշումը հաստատված կառավարման հարթությունից և աշխատող ծառայությունից։ Առաջին ձախողումը, որին հաջորդում է հաջողությունը, նույնպես ապացույց չէ, որ թունելը պետք է բարձրանար այդ ընթացքում, և գրանցեք փուլը և վիճակի փոփոխությունը։

Սկսեք ներքին tuple-ից, կանգ առեք առաջին այն փուլում, որը հակասում է նախագծին, և միայն այնուհետև դիմեք վերջնակետային ապացույցներին։ Հետագիծը քաղաքականության օրակուլ է, ոչ թե առաքման անդորրագիր։