Azure NVA ստուգում. ինչու է պատասխանն անցնում մեկ այլ firewall-ով

Մասնաճյուղից Azure հոսքը կարող է ճիշտ երթուղղորդվել երկու ուղղություններով և այնուամենայնիվ ձախողվել, որովհետև երկու ուղղություններն անցնում են տարբեր սարքերով։ Հարցումը թողնում է մասնաճյուղը VPN-ով, իջնում NVA A-ի վրա և հասնում աշխատանքային բեռին։ Պատասխանը թողնում է աշխատանքային բեռը, համընկնում NVA B-ին ուղղված երթուղու հետ և մահանում այնտեղ։ Այդ պատկերի յուրաքանչյուր երթուղի վավեր է, և TCP սեսիան դեռ կոտրված է։

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Այդ բացը այստեղ ամբողջ թեման է. երթուղավորման կոնվերգենցիան և սեսիայի վիճակի սեփականությունը տարբեր խնդիրներ են, որոնք գծապատկերում նույնն են թվում։

Ինչ է իրականում ծրագրավորում Route Server-ը

Azure Route Server-ը peering է հաստատում աջակցվող BGP խոսողների հետ, սովորում նրանց երթուղիները և ծրագրավորում դրանք վիրտուալ ցանցի արդյունավետ երթուղիներում։ Սա կառավարման հարթության աշխատանք է։ Այն չի կարդում մատակարարի firewall-ի սեսիաների աղյուսակը և չգիտի, թե որ սարքն է թույլ տվել տվյալ միացումը։ Երկու հավասար արժեքով հաջորդ ցատկերը այս գործվածքի համար պարզապես նույն նախածանցին հասնելու երկու եղանակ են, և այն կօգտագործի դրանցից որևէ մեկը։

Այսպիսով, երթուղի սովորելը ապացուցում է հասանելիությունը։ Այն ոչինչ չի ապացուցում այն մասին, թե արդյոք մյուս ծայրի սարքը նախկինում տեսել է այս հոսքը։

Կարդացեք երկու ուղղությունները նախքան նախագծելը

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

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

Որտեղ է ապրում վիճակը

Վիճակով firewall-ը թույլ է տալիս միացումը և պահում աղյուսակի գրառում՝ հնգյակով բանալիով։ Պատասխանը պետք է հասնի այդ գրառումը պահող սարքին, կամ այդ սարքը պետք է վիճակը ստանա այլ կերպ։ Azure-ի տվյալների հարթությունում ոչինչ գրառումը չի փոխանցում սարքերի միջև։ Կամ երթևեկությունը հետ է ուղղորդվում սեփականատիրոջը, կամ սարքերը վիճակը կիսում են մատակարարի մեխանիզմով, կամ նախագիծը չի աշխատում։

Այդ պատճառով երկու առողջ NVA-ն ստուգման համար առողջության ստուգում չէ։ Առողջությունը հասանելիության մասին է. ստուգումը՝ այն մասին, թե որ օրինակն է պահում սեսիան։

Աջակցվող HA մոդելները և ինչ է խոստանում յուրաքանչյուրը

Microsoft's guidance on Virtual WAN երթուղավորման մտադրության մասին նկարագրում է սահմանափակ վարք երկակի դերով կապի և firewall NVA-ների համար, որտեղ ուղիղ երթուղավորումը կարող է շրջանցել hub-ի սովորական սիմետրիկ կիրառումը։ Կարդացեք այդ նշումները որպես ձեր ընտրած տոպոլոգիայի սահմանափակումներ, ոչ որպես ակտիվ-ակտիվ նախագծերի արգելք։ Մատակարարի զույգը, որը համաժամեցնում է վիճակը կամ ուղղորդում է հոսքով, կարող է աջակցվել։ Հավասար արժեքով զույգը, որը ոչ մեկը չի անում, աջակցված չէ։

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

Ինչ փորձարկել նախքան դրան վստահելը

Test with inspection enabled and աշխատանքային բեռի մուտքի քաղաքականությունը տեղում, որովհետև դրանցից ցանկացածը կարող է թաքցնել ասիմետրիան։ Ուղարկեք նոր լիազորված հոսք երկու ուղղություններով և հաստատեք, որ նույն սարքը տեսել է երկու կեսերը։ Այնուհետև գործարկեք շարունակական երթևեկություն և գործարկեք հաստատված failover-ը՝ դիտելով, թե արդյոք հաստատված սեսիաները գոյատևում են, թե վերամիանում։

Կապակցրեք յուրաքանչյուր հոսքը այն սարքի հետ, որը մշակել է այն։ Մեկ NVA-ի վրա փաթեթների գրավումը գրեթե ոչինչ չի ասում, եթե պատասխանը երբեք չի վերադարձել այնտեղ։

Վերջում գրեք պլանը որպես երեք առանձին տող՝ երթուղիների սեփականություն, երթևեկության ուղղորդում և սեսիայի վիճակի սեփականություն։ Նախագծերը կոտրվում են, երբ առաջին երկուսը լուծված են, իսկ երրորդը ենթադրվում է։