Cisco ASA-ի tunneled լռելյայն երթուղին՝ երբ է այն իրականում կիրառվում

Հեռավոր մուտքի օգտատերը ոչ մի բանի չի հասնում ASA-ից այն կողմ, մինչդեռ նույն սերվերը պատասխանում է ներքին LAN-ից եկող ping-երին։ Թունելը բարձրանում է, հաճախորդը հասցե է ստանում pool-ից, և փաթեթը դեռ դուրս է գալիս ինտերնետի լռելյայն երթուղով կամ անհետանում։ Այս օրինաչափությունը սովորաբար նշանակում է, որ ապակոդավորված թրաֆիկը չի գտել սեփական երթուղի և ընկել է սովորական լռելյայն երթուղու վրա։ Լուծումը ևս մեկ NAT կանոն չէ. լուծումը tunneled լռելյայն երթուղին է։

Սկսեք ախտանիշից, ոչ թե կարգաբերումից

Նայեք, թե ուր է գնում փաթեթը, այլ ոչ թե ուր էիք սպասում, որ այն կգնա։ Արտաքին ինտերֆեյսի վրա ձախողված սեանսի ընթացքում արված capture-ը ցույց է տալիս ապակոդավորված փաթեթը, որը շարժվում է դեպի ISP-ի gateway-ը, իսկ pool-ի հասցեն դեռ անփոփոխ է, կամ ընդհանրապես ոչինչ չի ցույց տալիս, քանի որ որոնումը ձախողվել է։ Երկու դեպքում էլ թունելը խնդիրը չէ։

show vpn-sessiondb-ում թունելը առողջ է երևում, և հենց դա է պատճառը, որ մարդիկ շարունակում են debug անել IKE-ը։

ACL-ով անկումից սա տարբերվում է ուղղությամբ։ ACL-ով անկումը գրանցվում և հաշվվում է, մինչդեռ բացակայող երթուղին առաջացնում է որոնման ձախողում՝ առանց համապատասխան գրառման։ Գործարկեք show route հաճախորդի նպատակակետի համար և կարդացեք, թե ինչ է իրականում ընտրել ASA-ն, ներառյալ՝ արդյոք լռելյայն երթուղի է ընտրվել և որը։

Ինչո՞վ է տարբերվում tunneled որոնումը

Cisco-ի ASA 9.23 ստատիկ երթուղավորման ուղեցույցը նկարագրում է առանձին լռելյայն երթուղի ապակոդավորված VPN թրաֆիկի համար, որը չունի ստատիկ կամ սովորած երթուղի։ tunneled բանալի բառը նշում է այդ երթուղին, ուստի ապակոդավորված փաթեթը կարող է ընկնել այլ հաջորդ hop-ի վրա, քան այն, որն ASA-ն օգտագործում է իր սեփական տրանսպորտի համար։ Ավելի կոնկրետ երթուղիները դեռ հաղթում են, դրա համար էլ հաճախորդը կարող է ներքին gateway-ով հասնել 10.0.0.0/8-ին և կորցնել մնացած ամեն ինչ։

Նվազագույն դասավորությունը պահում է երկու լռելյայն երթուղի տարբեր հաջորդ hop-երով։ Մեկը կրում է ASA-ի սեփական թրաֆիկը, մյուսը՝ ապակոդավորված թրաֆիկը, որը լավագույն երթուղի չունի։ Երկու հաջորդ hop-երն էլ պետք է հասանելի լինեն այն ինտերֆեյսից, որին դուք դրանք կապում եք։

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Եթե երկու լռելյայն երթուղիներն էլ ուղղված են նույն հաջորդ hop-ին, բանալի բառը ոչինչ չի փոխում, և ախտանիշը չի շարժվի։

Սահմանափակումները, որոնք որոշում են՝ արդյոք այն կաշխատի

Նույն ուղեցույցը թույլ է տալիս միայն մեկ tunneled լռելյայն երթուղի և նշում, որ ECMP-ն դրա համար աջակցված չէ, ուստի այդ ուղով բեռը հավասարաչափ չեք բաշխի։ Այն նաև թվարկում է սահմանափակումներ՝ կապված երթուղիների հետևման, հակառակ ուղու ստուգման և որոշ inspection ու կառավարման հոսքերի հետ։ Կարդացեք դրանք ձեր տեղադրված release-ի համեմատ, նախքան այդ գործառույթի շուրջ ձևավորելը։ Դրանք անտեսող ձևավորումը սովորաբար ձախողվում է ոչ թե ամենուր, այլ մեկ կոնկրետ տեղում, դրա համար էլ ախտանիշը ընդհատվող է թվում։

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

Երթուղիների հետևումը առանձին թակարդ է. հետևվող օբյեկտը սովորաբար պաշտպանում է սովորական լռելյայն երթուղին, ոչ թե tunneled-ը։

Ինչ չի անում բանալի բառը

Այն չի ընտրում աղբյուրի հասցեն, որն ASA-ն օգտագործում է IKE կառուցելու համար։ Թունելի արտաքին վերջնակետը հետևում է հարթակի սեփական ինտերֆեյսի և աղբյուրի ընտրությանը, և tunneled լռելյայն երթուղին որևէ մաս չունի այդ որոշման մեջ։ Այն փոխելը չի վերանորոգի սխալ հասցեից սկսվող phase 1-ը։

Այն նաև հաջորդ hop-ը proxy չի դարձնում։ Եթե նպատակակետը սպասում է HTTP CONNECT փոխանակման, ապա proxy հոսթին չմշակված IP փաթեթներ ուղարկելը ձեզ տալիս է միայն հոսթ, որը դրանք չի երթուղավորում։ Փոխարենը կարգաբերեք հաճախորդի աջակցած proxy մեխանիզմը։

Եվ այն չի ստեղծում ներքև հոսքի փոխանցում։ Gateway-ին, որին ուղղված եք, դեռ պետք է երթուղի դեպի VPN pool, ինչպես նաև աղբյուրի թարգմանություն այնտեղ, որտեղ ձևավորումը դա պահանջում է։

Ստուգեք ուղին ծայրից ծայր

Երթուղին տեղադրելուց հետո հերթով ստուգեք չորս բան. show route՝ pool-ին անհրաժեշտ նպատակակետի համար, capture՝ նոր հաջորդ hop-ի ուղղությամբ ինտերֆեյսի վրա, capture՝ հենց gateway-ի վրա, և վերադարձի ուղի այդ gateway-ից դեպի pool-ի հասցեն։ Առաջին երկուսն ապացուցում են, որ ASA-ն ընտրել է ուղին, իսկ վերջին երկուսը՝ որ ինչ-որ մեկը պատասխանում է դրա վրա։

Եթե gateway-ը պատասխանում է, բայց հաճախորդը երբեք պատասխան չի տեսնում, նայեք աղբյուրի թարգմանությանը և վերադարձի երթուղուն, նախքան երթուղիների աղյուսակին նորից ձեռք տալը։

Գրանցեք այն release-ը, որի վրա ստուգել եք, որովհետև սահմանափակումների ցանկը տարբեր է ըստ տարբերակի, և մի ճյուղում աշխատող ձևավորումը կարող է մյուսում այլ ուղի պահանջել։ Այդ նշումը ավելի երկար է ապրում, քան կարգաբերման հատվածը։