AWS Client VPN-ի հաճախորդի CIDR-ը չի կարող համընկնել VPC-ի տիրույթի հետ
AWS-ը Client VPN-ի փուլը ամրագրում է ստեղծման պահին, իսկ համընկնումը որոշվում է տիրույթներով, ոչ թե չօգտագործված հասցեներով։ Հինգ ստուգում՝ կառուցելուց առաջ։
AWS Client VPN-ի վերջնակետը հաճախորդի հասցեներ է բաժանում ձեր ընտրած փուլից, և AWS-ը ստուգում է այդ փուլը թիրախ ցանցի դիմաց մինչև վերջնակետի ստեղծումը։ Ստուգումը այն մասին չէ, թե ենթացանցը ազատ է թվում։ Այն մասին է, թե փուլը համընկնում է VPC-ի տիրույթի հետ, և պատասխանը նույնն է՝ անկախ նրանից, այսօր որևէ EC2 օրինակ օգտագործում է այդ հասցեները, թե ոչ։ Համընկնումը տիրույթների հարց է, ոչ բաշխումների։
Անցեք հինգ ստուգում հերթականությամբ։ Կանգ առեք առաջինում, որը ձախողվում է, որովհետև ոչ մի հետագա քայլ չի կարող ուղղել ավելի վաղ որոշումը։
Համընկնումը տիրույթների թեստ է, ոչ ազատ հասցեների թեստ
Սկսեք VPC-ի CIDR-ից, ոչ այն ենթացանցից, որը պատրաստվում եք միացնել։ 172.20.0.0/22 փուլը գտնվում է 172.20.0.0/16 VPC-ի ներսում և մերժվում է նույնիսկ այն դեպքում, երբ ոչ մի ենթացանց այն չի զբաղեցնում, որովհետև համընկնումը տիրույթների հատկություն է, ոչ ընթացիկ բաշխումների։ Այնուհետև ավելացրեք այն նպատակակետերը, որոնց վերջնակետը երթուղավորում է՝ peered VPC-ներ, transit gateway և տեղական տիրույթներ site-to-site կապով։ Ցանկացած տիրույթ, որին հաճախորդը կարող է կարիք ունենալ հասնելու, պատկանում է ցանկին։
Հավաքեք դրանք հաշվից, ոչ հիշողությունից՝ aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", գումարած այն ենթացանցի երթուղային աղյուսակի գրառումները, որը պատրաստվում եք միացնել։
Փուլի չափը որոշվում է կառուցելուց առաջ
AWS-ը Client VPN-ում ընդունում է IPv4 հաճախորդի փուլ /22-ից /12 միջակայքում։ /24-ը չափազանց փոքր է, /8-ը դուրս է փաստագրված տիրույթից, և երկու սխալներն էլ գալիս են փուլը աշխատանքային ծանրաբեռնվածության ենթացանցի պես չափելուց։ Չափեք այն սպասվող միաժամանակյա հաճախորդներով և պահուստով, ապա կլորացրեք թույլատրելի նախածանցի։
Ստուգեք թվաբանությունը նախքան այն կոնսոլում մուտքագրելը, որովհետև սխալ մուտքագրված նախածանցը փոխում է փուլի չափը առանց որևէ նախազգուշացման։
python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"Դա տպում է հասցեների քանակը, նախածանցի երկարությունը և այն՝ արդյոք թեկնածուն բախվում է VPC-ի տիրույթի հետ, ինչն ավելի արագ է, քան փոփոխությունների պատուհանի վերջում ցանցային դիմակների մասին մտածելը։
Resolver-ն ունի իր սեփական հասցեի դերը
VPC-ի resolver-ը պատասխանում է VPC-ի տիրույթի բազային հասցեին գումարած երկու, ինչը պարտադիր չէ, որ լինի ձեր միացրած ենթացանցի ներսում։ Այն ենթադրությունը, որ resolver-ը պետք է ապրի հաճախորդի փուլում, կամ այդ հասցեի շուրջ ենթացանց կառուցելը, ավելացնում է օբյեկտներ՝ առանց որևէ բան փոխելու։ Կարևորն այն է, որ վերջնակետը կրում է DNS կարգավորում, որը հաճախորդը կարող է կիրառել, և որ resolver-ը հասանելի է թունելից։
Գրանցեք resolver-ը, հաճախորդի փուլը և միացված ենթացանցը որպես երեք առանձին կետ հասցեների պլանում։ Դրանք ձախողվում են անկախ, և մեկի ճիշտ լինելը ոչինչ չի ասում մյուս երկուսի մասին։
Չորս դաշտ, որոնց պարտավորվում եք ստեղծման պահին
Հաճախորդի IPv4 CIDR-ը ամրագրված է ստեղծման պահին։ DNS սերվերը փոխելը, միացում ավելացնելը, անվտանգության խումբը փոխելը, լիազորման կանոնները խմբագրելը կամ split-tunnel երթուղիները փոխելը սովորական խմբագրումներ են, և դրանցից ոչ մեկը չի վերանվանում փուլը։ Այդ անհամաչափությունն է պատճառը, որ սա արժանի է վերանայման՝ էժան կարգավորումներն այն են, որ կուզենաք փոխել ավելի ուշ, իսկ թանկը՝ այն, ինչին առաջինը պարտավորվում եք։ Կարդացեք վերջնակետի նկարագրությունը նախքան փոփոխությունների պատուհան պլանավորելը։
Ստուգեք տեղակայված վերջնակետը նախքան վերակառուցում ենթադրելը։ aws ec2 describe-client-vpn-endpoints-ը վերադարձնում է փուլը, DNS-ը, split-tunnel դրոշը և միացումները մեկ պատասխանում, ինչը սովորաբար բավական է վերակառուցումը բացառելու համար։
Փոխարինեք վերջնակետը, մի՛ կարկատեք այն
Նոր վերջնակետը նոր վերջնակետ է, ոչ միգրացիա։ Գործող սեսիաները չեն տեղափոխվում դրան, հաճախորդի պրոֆիլները ցույց են տալիս այլ անուն, և յուրաքանչյուր կարգավորում, որ ընդունում էիք որպես ինքնըստինքյան, պետք է վերստեղծվի՝ սերվերի վկայական, նույնականացում, միացումներ, երթուղիներ, լիազորման խմբեր, մատյանագրում։ Ստուգեք մեկ հաճախորդով պարտադիր մասնավոր ծառայության դիմաց և մի նպատակակետի դիմաց, որը պետք է մերժվի, ապա ընդլայնեք հասանելիությունը։ Այն ամենը, ինչ բաց կթողնեք, ավելի ուշ կդառնա աջակցության տոմս։
Թողեք հին վերջնակետը աշխատի, մինչև այդ ստուգումը անցնի, և պահպանեք վարչական ուղի, որը կախված չէ նորից։
Մեկ սահման, որ արժե նշել՝ սա ընդգրկում է IPv4 հաճախորդի փուլը։ Client VPN-ում dual-stack և IPv6 թրաֆիկի կարգավորումները հետևում են իրենց սեփական հասցեավորման մոդելին, ուստի մի պատճենեք այս ցանկը առանց այդ ռեժիմի փաստաթղթերը կարդալու։