Ստատիկ IP Azure P2S VPN-ում. ինչու է փոխվում հաճախորդի հասցեն
Azure point-to-site-ը յուրաքանչյուր միացման ժամանակ տալիս է լողավազանի հաջորդ ազատ հասցեն, ուստի հաճախորդի ֆիքսված IP գոյություն չունի։ Հասանելիությունը կապեք միջակայքերին կամ ինքնությանը։
Յուրաքանչյուր Azure point-to-site հաճախորդ ստանում է հասցե լողավազանից, երբ նույնականացնում է իրեն, և պահում է այն միայն այդ միացման տևողության ընթացքում։ Չկա արգելոցային աղյուսակ, չկա օգտատիրոջով քարտեզագրում, և չկա դարպասի այնպիսի կարգավորում, որը նշանակի «միշտ տուր այս անձին 172.16.0.10»։ Հենց այդ մեկ մեխանիզմն է բացատրում երկու ախտանիշները, որոնց մարդիկ հանդիպում են ավելի ուշ. NSG կանոն, որը դադարում է համապատասխանել այն օգտատիրոջը, ում նախկինում համապատասխանում էր, և թույլատրելիների ցանկ, որը լուռ ներս է թողնում մեքենա, որը ոչ ոք դիտավորյալ չի ավելացրել։ Կանոնը ավելի խելացի IP կանոնով փոխարինելը ոչ մեկին չի ուղղում, որովհետև այն, ինչ կանոնը անվանում է, վերաբաշխվում է ձեր չվերահսկած ժամանակացույցով։
Լողավազանը տարողություն է, ոչ ինքնություն։ Այն գոյություն ունի, որպեսզի միաժամանակյա թունելները ստանան եզակի հասցեներ, և վերամշակում է դրանք վարձակալության ավարտի պահին։ Երբ դա պարզ է, օգտակար հարցը դադարում է «ինչպես ամրացնեմ այս հաճախորդին» լինելուց և դառնում է «ինչի դեմ կարող եմ կանոն գրել, որը դարպասը չի վերամշակի»։
Ինչ է իրականում անում դարպասը, երբ հաճախորդը միանում է
Դարպասը պահում է կարգավորված հաճախորդի հասցեների լողավազանը և վերաբերվում է նրան որպես վարձակալությունների աղյուսակ։ Միանալիս վերցնում է հաջորդ ազատ հասցեն, գործնականում ամենացածր հասանելիը, և հատկացնում այն թունելի ադապտերին, մինչև հաճախորդը անջատվի կամ վարձակալությունը լրանա։ Որոշում է հերթականությունը, ոչ ինքնությունը. ով հանգիստ շրջանից հետո առաջինը նորից միանա, կստանա ամենացածր հասցեն, որն այդ պահին պատահաբար ազատ է։
Լողավազանի չափը թաքցնում է վարքը։ Փորձարկողների թվից մեկ-երկու հասցեով մեծ լաբորատոր լողավազանը դետերմինիստական է թվում, որովհետև նույն նոութբուքը սովորաբար ամեն առավոտ նույն հերթականությամբ նորից միանում է։ Ավելացրեք երրորդ մեքենա, փոխեք լողավազանի չափը կամ թողեք սեսիան միացված ճաշի ընթացքում, և օրինաչափությունը կոտրվում է։ Հասցեն երբեք կայուն չի եղել. հերթն էր։
point-to-site կարգավորման ցանկացած փոփոխություն նաև զրոյացնում է վարձակալության տարածքը։ Այլ նույնականացման տեսակ, չափափոխված լողավազան, նոր լողավազանի միջակայք կամ քանդված ու նորից կառուցված դարպաս. բոլորը հաճախորդներին հետ են ուղարկում լողավազան, որն այլևս չի համապատասխանում նրանց հին հասցեներին։ Այդ փոփոխության ոչինչ չի դիպչում ձեր NSG-ին, դրա համար էլ խափանումը ինքնաբուխ է թվում։
Դա կարելի է տեսնել մոտ մեկ րոպեում։ Միացեք, գրանցեք թունելի հասցեն հաճախորդի միացման մանրամասներում, անջատվեք, միացրեք երկրորդ մեքենան, ապա նորից միացրեք առաջինը։ Ստացված հասցեն կախված է նրանից, ինչ պահում է երկրորդ մեքենան, և ոչ մի պորտալի կարգավորում չի վերականգնի նախորդը պահանջով։
Հաճախորդի IP-ի վրա հիմնված NSG-ն իրականում միացման հերթականության մասին կանոն է
Այն կանոնը, որ մարդիկ առաջինն են գրում, ակնհայտն է. ներգնա կանոն կառավարման VM-ի NIC-ի կամ դրա ենթացանցի վրա, որպես աղբյուր VPN հաճախորդի ներքին հասցեն։ Կարճ է, անցնում է թեստը գրելու օրը և ձախողվում է հենց որ լողավազանում մեկից ավելի ազատ հասցե լինի։
Դրանից բխում են ձախողման երկու եղանակ, և միայն մեկն է սխալի տեսք ունենում։ Օրինական օգտատերը մերժվում է, որովհետև այդ պահին ուրիշը պահում է այն հասցեն, որը անվանում է կանոնը, և դա գալիս է որպես նյարդայնացնող աջակցության տոմս։ Կամ չնախատեսված օգտատերը թույլատրվում է, որովհետև ժառանգել է հասցե, որին կանոնը դեռ վստահում է, և դա ոչինչ չի գալիս այնքան ժամանակ, քանի դեռ ինչ-որ մեկը չստուգի հասանելիությունը։
Քանի որ կանոնը հետևում է վարձակալությանը, փաստացի քաղաքականությունն ասում է՝ «ով առաջինը միանա, կստանա կառավարման հասանելիություն»։ Դա միացման հերթականության նկարագրություն է՝ դիտավորության հանդերձանքով, և ոչ մի կանոնային հիգիենա այն դիտավորության արտահայտություն չի դարձնում։
Հաճախորդի վարձակալությունը և դարպասի հասցեն տարբեր օբյեկտներ են
Շփոթության մեծ մասը գալիս է մեկ բառից։ Դարպասն ունի համեմատաբար կայուն հանրային IP. հաճախորդներն ունեն լողավազանից մասնավոր հասցեներ, որոնք կայուն չեն։ Ոչ զոնային կրկնապատկմամբ VPN դարպասի համար հանրային IP-ն հատկացվում է դինամիկ, բայց այն վերապրում է չափի փոփոխությունը, վերակայումը և սովորական սպասարկումը. այն փոխվում է, երբ դարպասն ինքն է ջնջվում և նորից ստեղծվում։ Զոնային կրկնապատկմամբ և զոնալ դարպասի SKU-ները օգտագործում են Standard SKU-ի հանրային IP, և այդ հատկացումը պետք է լինի ստատիկ։
Այդ կայունությունն է, ինչ տեղական գործընկերոջն անհրաժեշտ է իր կարգավորման մեջ, և այն ոչինչ չի ասում առանձին հաճախորդի նույնականացման մասին։ Երբ գործընկերը հարցնում է, թե որ հասցեն կտեսնի, պատասխանը դարպասի հանրային IP-ն է site-to-site-ում կամ ընդհանուր NAT միջակայք. երբեք նոութբուքի թունելի վարձակալությունը։
Խմբային լողավազանները ձեզ տալիս են միջակայք, որի դեմ արժե կանոններ գրել
Virtual WAN point-to-site-ը աջակցում է օգտատերերի խմբերին, և յուրաքանչյուր խմբի կարելի է հատկացնել իր հաճախորդի հասցեների լողավազանը։ Անդամակցությունը որոշվում է ինքնությամբ, ուստի միջակայքը, որտեղ հայտնվում է հաճախորդը, դառնում է կանխատեսելի. գործառնությունները մեկ միջակայքում, կապալառուները մյուսում, և միջակայքն այն բանն է, որը firewall-ի կամ NSG-ի կանոնը կարող է անվանել առանց գուշակելու։
Ստացված կանոնների հավաքածուն այնպիսի ձև ունի, որը կարող եք վերանայել.
- մեկ լողավազան յուրաքանչյուր լսարանի համար, չափված գագաթնակետային միաժամանակյա սեսիաներով, ոչ թե մարդկանց թվով.
- խմբի անդամակցությունը ղեկավարվում է ինքնությամբ, ոչ թե կանոնները խմբագրելով ամեն անգամ, երբ ինչ-որ մեկը միանում է.
- NSG կամ Azure Firewall կանոնները գրվում են լողավազանի միջակայքերի դեմ, երբեք առանձին վարձակալությունների դեմ.
- առանձին հանգույց կամ դարպաս այն լսարանների համար, որոնք երբեք չպետք է կիսեն միջակայք։
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
Ամբողջ լողավազանը թույլատրելիների ցանկում դնելը ազնիվ է, բայց կոպիտ. այդ միջակայքի յուրաքանչյուր միացած հաճախորդ ստանում է նույն հասանելիությունը։ Դա քաղաքականության որոշում է, որն արժե բարձրաձայն ասել, փոխանակ վերանայման ժամանակ հայտնաբերելու։ Այն ամենը, ինչ դեռ պահանջում է պատասխան յուրաքանչյուր անձի համար, պատկանում է ռեսուրսին՝ դերերի հատկացումների միջոցով, ոչ թե փաթեթների զտիչին։
Երբ տեղադրումը չի կարող անցնել Virtual WAN-ին
Շատ դարպասներ մնում են սովորական VPN դարպասներ, և Virtual WAN-ին անցնելը պատահական փոփոխություն չէ։ Գործնական պատասխանն այն է, որ յուրաքանչյուր օգտատիրոջ որոշումը փաթեթների զտիչից տեղափոխվի մի բանի, որն արդեն գիտի, թե ով է օգտատերը։
Ռեսուրսի մակարդակի ինքնությունը ամենաէժան տարբերակն է։ Storage-ը, SQL-ը և Key Vault-ը բոլորն աջակցում են Entra ID նույնականացմանը՝ օգտատիրոջ կամ խմբի դերերի հատկացումներով, ուստի VPN-ին մնում է միայն ապացուցել ցանցային հասանելիությունը։ Անվանված հաշիվներով ցատկող հոսթը նույն գործն է անում վարչական աշխատանքի համար, որովհետև հոսթը գրանցում է մարդուն, իսկ թունելը միայն փաթեթներ է փոխադրում։ Հաճախորդներին DNS-ում գրանցելը և թվի փոխարեն անունը թույլատրելը կանոնը մեկ շերտ բարձրացնում է։ Հավելվածի մակարդակի ինքնությունը՝ սերտիֆիկատի սուբյեկտ, թոքենի պնդում, խմբի անդամակցություն, աշխատում է, երբ որոշելու համար հարցնում են հավելվածին, ոչ թե ցանցին։
Գործընկերոջը, որը պնդում է ֆիքսված աղբյուրի հասցե, պատասխանը site-to-site-ն է կամ ExpressRoute-ը՝ սահմանված գործընկերոջ նախածանցով։ Նրանք թույլատրում են գործընկերոջ նախածանցը, նրանց կողմում հայտնվող հասցեն պատկանում է դարպասին, և այն չի փոխվում, երբ ինչ-որ մեկը վերագործարկում է նոութբուքը։
Ստուգեք լողավազանը, նախքան ևս մեկ թույլատրելիների ցանկ խմբագրելը
Լողավազանի երկու հատկություն առաջացնում են այն վարքի մեծ մասը, որի համար մարդիկ մեղադրում են հաճախորդին։ Չափազանց փոքր լողավազանը արագ վերամշակում է վարձակալությունները, ուստի հասցեները անընդհատ շարժվող են թվում, և հասցեի վրա հիմնված ցանկացած կանոն ի սկզբանե անկայուն է թվում։ Լողավազանը, որը համընկնում է տեղական միջակայքերի կամ վիրտուալ ցանցի հասցեային տարածքի հետ, ստեղծում է երթուղավորման երկիմաստություն, որը ոչ մի firewall կանոն չի վերացնում։
Նախքան կանոնին դիպչելը երեք բան դրեք մեկ էջում. point-to-site լողավազանը, վիրտուալ ցանցի հասցեային տարածքը և տեղական միջակայքերը։ Դրանք չպետք է համընկնեն, և լողավազանին տեղ է պետք յուրաքանչյուր միաժամանակյա հաճախորդի համար գումարած լուսանցք՝ նոր միացումների համար։
Ապա փակեք շրջանակը այս հերթականությամբ.
- Միացեք երկու մեքենաներից երկու հերթականությամբ և համեմատեք հասցեները. եթե դրանք կարող են փոխվել, ապա հասցեի վրա հիմնված ոչ մի կանոն ապահով չէ։
- Ստուգեք՝ դարպասը Virtual WAN է, թե ոչ. եթե այո, օգտագործեք խմբային լողավազաններ՝ հասցեով կանոնների փոխարեն։
- Հարցրեք, թե ինչ է լինում, երբ կանոնը դիպչում է սխալ անձի. եթե պատասխանը հասանելիության միջադեպ է, վերահսկողությունը տեղափոխեք ինքնության։
- Գրանցեք, թե որ միջակայքն է պատկանում որ խմբին, նույն պահոցում, որտեղ NSG-ի սահմանումներն են։
- Կրկին փորձարկեք լողավազանի, նույնականացման կամ դարպասի ցանկացած փոփոխությունից հետո, որովհետև այդ փոփոխությունները վերաշարադրում են քարտեզագրումը՝ առանց հայտարարելու։