Cisco ASA-ից դեպի Azure VPN՝ տրաֆիկի սելեկտորի նախածանցային զույգեր

Թունելը բարձրանում է, IKE-ն առողջ է թվում, և ոչինչ չի անցնում դրա միջով։ Սա ASA-ից Azure ընտրիչի խնդրի սովորական պատկերն է, և ահա թե ինչու ես պայմանագիրը գրում եմ նախքան կոնսոլներից որևէ մեկին դիպչելը։ Պայմանագիրը չորս բան է՝ յուրաքանչյուր զուգընկերոջը նույնականացնող օբյեկտները, միացման մոդելը, ճշգրիտ նախածանցային զույգերը և ստուգումը, որն ապացուցում է յուրաքանչյուր զույգը։ Սխալեք այս չորսում, և յուրաքանչյուր հետագա հրաման կզբաղվի մի կոնֆիգուրացիայի վրիպազերծմամբ, որը դուք չպետք է կառուցեիք։ Այս ձեռնարկը այն հերթականությունն է, որն ես օգտագործում եմ, այն հրամաններով, որոնք ցույց են տալիս, թե որ օբյեկտն է իրականում սխալ։

Նախքան կարգաբերելը գրի առեք չորս օբյեկտները

Սկսեք ASA-ի թողարկումից և հարթակից, հանրային վերջնակետից, Azure VPN դարպասի տեսակից և SKU-ից, և ձեր կողմը ներկայացնող տեղական ցանցի դարպասից։ Այդ չորս անվանումները բառապաշարն են այն ամենի համար, ինչ հաջորդում է, և յուրաքանչյուրն ունի տարբեր պատասխանատու, երբ ինչ-որ բան խափանվում է։

Եթե դրանցից երկուսը դեռ ենթադրություններ են, կանգ առեք։ Տեղական ցանցի դարպասի սխալ նախածանցային ցանկը կարգավորման խնդիր չէ։

Ընտրեք միացման մեկ մոդել և դադարեցրեք ձևանմուշների խառնումը

Կրիպտոքարտեզի ձևավորումը և թունելային ինտերֆեյսի ձևավորումը տարբեր կոնֆիգուրացիաներ են, և մեկի ձևանմուշը չի դառնում վավեր մյուսի համար՝ զուգընկերոջ հասցեն փոփոխելով։ Գրանցեք, թե որն եք կառուցում նախքան որևէ բան տեղադրելը, քանի որ անհամապատասխանությունը հետագայում ի հայտ է գալիս որպես ընտրիչի խնդիր, այլ ոչ թե կոնֆիգուրացիայի սխալ։ Microsoft-ի ASA փոխգործունակության ուղեցույցը ընդգրկում է երկու օրինաչափությունները և նշում, թե Azure դարպասի որ մոդելն է ենթադրում յուրաքանչյուրը։ Եթե ձեր նշումները չեն նշում մոդելը, դեռ ձևավորում չունեք։

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

Տարբերակների սահմանափակումները նույնպես տեղ ունեն պայմանագրում։ Հին դաշտային զեկույցը գաղտնագրման տիրույթների սահմանափակման մասին տվյալ է կոնկրետ թողարկումների վերաբերյալ, ոչ թե յուրաքանչյուր ASA-ի մշտական հատկություն։

Թվարկեք նախածանցային զույգերը, ոչ թե ագրեգատները

Գրեք մատրիցը։ Տեղական A-ն և B-ն դեպի Azure X և Y չորս զույգ է, և յուրաքանչյուրին պետք է ծածկույթ կամ բացահայտ բացառում։ A-ն և B-ն մեկ ագրեգատի մեջ միավորելը ներառում է նաև այն ամենը, ինչ գտնվում է նրանց միջև, և այդպես է ձևավորումը հանգիստ անցք բացում։

Ստուգեք, թե ինչ են բանակցել զուգընկերները, այլ ոչ թե ինչ եք պահել։ ASA-ի տեղական և հեռավոր ցանցերի ցանկը մտադրություն է. CHILD SA-ները՝ արդյունք։

Երբ զույգը բացակայում է, ուղղումը սովորաբար մուտքի ցանկի տող կամ ընտրիչի գրառում է, ոչ թե նոր թունել։

Ստուգեք օբյեկտը անվանող հրամաններով

ASA-ի վրա հաստատեք IKE նստաշրջանը, ապա IPsec SA-ները, ապա ընտրիչի զույգերը։ Յուրաքանչյուր հրաման տարբեր հարցի է պատասխանում, և միայն առաջինը գործարկելը այդպես է «թունելը բարձրացած է» դարձնում կեղծ եզրակացություն։ Կարդացեք ելքը ձեր իրականում կարգաբերված զուգընկերոջ համար, այլ ոչ թե ցանկում առաջին պատահած SA-ի։ Azure-ի կողմը պատասխանում է նույն երեք հարցերին իր տեսանկյունից։

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

Այնուհետև հարցրեք Azure-ին միացման վիճակի մասին az network vpn-connection show --name <connection> --query connectionStatus-ով։ «Միացած»՝ տվյալների ուղու զրո բայթերով, ընտրիչի խնդիր է, ոչ թե երթուղային։

Փորձարկեք յուրաքանչյուր զույգի համար մեկ թույլատրված հոսք, ստուգեք հեռավոր կողմում տեսանելի աղբյուրի հասցեն, և փորձեք մեկ ռեսուրս, որը պետք է մերժվի։ Այդ վերջին փորձարկումն է միայն ապացուցում, որ սահմանը դեռ գոյություն ունի։

Գաղտնագրման շրջանակը առանձին պահեք մուտքի թույլտվությունից

Լայն ընտրիչը թույլտվություն չէ։ Եթե աջակցվող դասավորությունն ավելի լայն է, քան հավելվածի քաղաքականությունը, նեղ ծառայությունները թողեք firewall-ի կանոններում և գաղտնագրման շրջանակը թողեք այնտեղ, որտեղ պետք է։

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

Հետադարձ և ապացույց, որ այն աշխատեց

Պահեք նախորդ աշխատող կոնֆիգուրացիան նախքան ընտրիչները փոխելը, և իմացեք այն մեկ հրամանը, որը վերադարձնում է այն։ ASA-ի վրա դա նշանակում է պահված պատճեն և համապատասխան վերականգնման ուղի, ոչ թե հիշողություն, թե ինչ եք փոխել։ Գրեք վերականգնման հրամանը փոփոխության տոմսի մեջ, քանի դեռ փոփոխությունը դեռ հիպոթետիկ է։ Այնուհետև նորից գործարկեք նույն երեք ստուգումները՝ IKE վիճակ, IPsec SA զույգեր, մեկ թույլատրված հոսք յուրաքանչյուր զույգի համար։

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