Որտեղ կիրառել NSG-ները Azure site-to-site VPN երթևեկության համար

Site-to-site թունելը աշխատում է, տեղական հաճախորդը հասնում է Azure-ի որոշ հոսթերի, իսկ մյուսներին՝ ոչ, և ինչ-որ մեկը դա շտկելու համար ցանցային անվտանգության խումբ է կցել GatewaySubnet-ին։ Կանգ առեք այստեղ։ Azure-ը չի աջակցում NSG GatewaySubnet-ի վրա, և խումբը չի տեսնում ներքին փաթեթը այնպես, ինչպես աշխատանքային ծանրաբեռնվածության կանոնը։ Տեղադրեք քաղաքականությունը նպատակակետ ենթացանցում կամ NIC-ում, համապատասխանեցրեք ապակոդավորումից հետո գոյություն ունեցող աղբյուրի հասցեն, ապա ստուգեք նոր միացումով, ոչ հինով։

Տեղադրեք NSG-ն այնտեղ, որտեղ Azure-ը գնահատում է այն

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

Տեղադրման մեջ կա նաև տրամաբանական խնդիր։ GatewaySubnet-ի NSG-ն կգնահատեր արտաքին IPsec փոխանակումը, որի հասցեները պատկանում են երկու դարպասներին։ Ձեր հավելվածի կանոնին անհրաժեշտ է թունելի ներսում գտնվող մասնավոր աղբյուրը, և այդ փաթեթը գոյություն ունի միայն այն բանից հետո, երբ դարպասը ապակոդավորի այն։ Կցեք խումբը աշխատանքային ծանրաբեռնվածության ենթացանցին, և կանոնը կտեսնի այն հասցեն, որի համար գրվել է։

Նախքան որևէ բան փոխելը ստուգեք ընթացիկ կապակցումները, որպեսզի իմանաք, թե ինչ եք տեղափոխում.

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Գտեք աղբյուրի հասցեն ապակոդավորումից հետո

Ներքին աղբյուրը տեղական հաճախորդի մասնավոր հասցեն է, կամ այն հասցեն, որը սարքը կամ VPN-ի NAT-ը ներկայացնում է թարգմանությունից հետո։ Սա տեղական VPN դարպասի հանրային հասցեն չէ, որը պատկանում է արտաքին փոխանակմանը։

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

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Օգտագործեք մեկ կանոն յուրաքանչյուր ծառայության համար, որը ցանկանում եք բացել, և պորտերի ցանկը կարճ պահեք։ Կանոնը, որը թույլ է տալիս բոլոր պորտերը տեղական միջակայքից, NSG-ն դարձնում է ձևականություն։

Ստուգեք VirtualNetwork-ի լռելյայն սահմանը

VirtualNetwork ծառայության պիտակը ավելի լայն է, քան տեղական վիրտուալ ցանցը։ Դրա սահմանումը ներառում է միացված տեղական հասցեային տարածություններ, peering-ով ցանցեր և դարպասին միացված այլ նախածանցներ։ Այսինքն՝ VirtualNetwork-ով սահմանափակված լռելյայն թույլտվության կանոնն արդեն կարող է թույլ տալ թունելի երթևեկություն, որը շահագործողը համարում էր արտաքին։

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

Microsoft-ի ծառայության պիտակների փաստաթղթերը թվարկում են, թե ինչ է ընդգրկում VirtualNetwork պիտակը, և դա այն հղումն է, որին վկայակոչում են, երբ ինչ-որ մեկը պնդում է, թե պիտակը նշանակում է միայն VNet-ի միջակայքը։

Կարդացեք գործող կանոնները երկու սահմաններում

Երբ գործում են և՛ ենթացանցի NSG-ն, և՛ NIC-ի NSG-ն, հոսքը պետք է բավարարի երկուսին։ Մեկում տրված թույլտվությունը չի վերացնում մյուսում տրված արգելքը, և փաթեթն իրականում հանդիպում է համախմբված պատկերին։

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Եթե գործում են Azure Virtual Network Manager-ի անվտանգության ադմինիստրատորի կանոնները, վերանայեք նաև այդ շերտը։ Ադմինիստրատիվ Always allow կանոնը կարող է երթևեկությունը հասցնել առանց NSG-ի գնահատման, մինչդեռ ադմինիստրատիվ Deny-ն կանգնեցնում է այն նախքան NSG-ները կտեսնեն։ Միայն NSG-ի վերանայումը թերի է այդ դասավորության համար։

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

Ստուգեք թարմ միացումով

Բացեք նոր սեսիա տեղական հաճախորդից դեպի ծառայության պորտը, ապա կրկնեք այն հոսթից, որը պետք է մերժվի։ Գործարկեք հոսքի թեստը նաև VM-ի կողմից, որպեսզի իմանաք, որ վերադարձի ուղին անվնաս է։

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

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