Hindi maaaring mag-overlap ang client CIDR ng AWS Client VPN sa hanay ng VPC

Ang endpoint ng AWS Client VPN ay namamahagi ng mga address ng client mula sa pool na pinipili mo, at sinisuri ng AWS ang pool na iyon laban sa target na network bago gawin ang endpoint. Ang pagsusuri ay hindi kung mukhang bakante ang isang subnet. Ito ay kung nag-overlap ang pool sa hanay ng VPC, at pareho ang sagot kahit gumagamit o hindi ng mga address na iyon ang isang instance ng EC2 ngayon. Ang overlap ay tanong tungkol sa mga hanay, hindi sa mga allotment.

Daanan ang limang pagsusuri sa pagkakasunod-sunod. Huminto sa unang mabibigo, dahil walang susunod na hakbang ang makakapag-ayos ng naunang desisyon.

Ang overlap ay pagsubok sa mga hanay, hindi pagsubok sa mga bakanteng address

Magsimula sa CIDR ng VPC, hindi sa subnet na balak mong iugnay. Ang pool na 172.20.0.0/22 ay nasa loob ng VPC na 172.20.0.0/16 at tinatanggihan kahit walang subnet na sumasakop dito, dahil ang overlap ay katangian ng mga hanay, hindi ng kasalukuyang allotment. Pagkatapos idagdag ang mga destinasyon na pinaglalagian ng endpoint: peer VPC, transit gateway, at mga on-premises na hanay sa pamamagitan ng site-to-site na koneksyon. Anumang hanay na maaaring kailangang maabot ng client ay kasama sa listahan.

Kolektahin ang mga ito mula sa account, hindi sa alaala: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", kasama ang mga entry sa route table para sa subnet na balak mong iugnay.

Ang laki ng pool ay pinagpapasyahan bago magtayo

Tumatanggap ang AWS ng IPv4 client pool sa pagitan ng /22 at /12 sa Client VPN. Ang /24 ay masyadong maliit, ang /8 ay labas ng dokumentadong hanay, at ang dalawang pagkakamali ay nagmumula sa pagsukat ng pool na parang subnet ng workload. Sukatin ito ayon sa inaasahang sabay na client at margin, pagkatapos i-round sa pinapayagang prefix.

Suriin ang aritmetika bago ito i-type sa console, dahil ang maling na-type na prefix ay nagbabago ng laki ng pool nang walang anumang babala:

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')))"

Ipinapakita nito ang bilang ng address, haba ng prefix, at kung bumabangga ang kandidato sa hanay ng VPC, na mas mabilis kaysa mag-isip tungkol sa netmask sa dulo ng window ng pagbabago.

May sariling tungkulin sa address ang resolver

Sumasagot ang resolver ng VPC sa base address ng hanay ng VPC dagdag dalawa, na hindi laging nasa loob ng subnet na iniugnay mo. Ang pag-aakalang kailangang manirahan ng resolver sa client pool, o ang paggawa ng subnet sa paligid ng address na iyon, ay nagdadagdag ng mga bagay nang walang binabago. Ang mahalaga ay may dalang setting ng DNS ang endpoint na magagamit ng client at naaabot ang resolver mula sa tunnel.

Itala ang resolver, client pool, at iniugnay na subnet bilang tatlong hiwalay na item sa plano ng address. Nabibigo ang mga ito nang hiwalay, at ang isang tama ay walang sinasabi tungkol sa dalawa.

Apat na field na pinanghahawakan mo sa paggawa

Ang IPv4 CIDR ng client ay nakatakda sa paggawa. Ang pagpalit ng DNS server, pagdagdag ng association, pagpalit ng security group, pag-edit ng authorization rules, o pagbabago ng split-tunnel routes ay karaniwang pag-edit, at wala sa mga ito ang nagpapalit ng pangalan ng pool. Ang kawalan ng simetrya ay ang dahilan kung bakit karapat-dapat itong suriin: ang murang setting ang gusto mong baguhin mamaya, at ang mamahalin ang pinanghahawakan mo muna. Basahin ang paglalarawan ng endpoint bago magplano ng window ng pagbabago.

Siyasatin ang naka-deploy na endpoint bago mag-akala ng muling pagtatayo. Ibinabalik ng aws ec2 describe-client-vpn-endpoints ang pool, DNS, flag ng split-tunnel, at mga association sa isang tugon, na kadalasan ay sapat para maalis ang muling pagtatayo.

Palitan ang endpoint sa halip na tapalan ito

Ang bagong endpoint ay bagong endpoint, hindi migrasyon. Hindi lumilipat doon ang mga existing session, ibang pangalan ang tinutukoy ng mga client profile, at bawat setting na inaakala mong natural ay dapat gawing muli: server certificate, authentication, associations, routes, authorization groups, logging. I-validate gamit ang isang client laban sa kinakailangang pribadong serbisyo at laban sa destinasyong dapat tanggihan, pagkatapos palawakin ang access. Anumang laktawan mo ay magiging support ticket mamaya.

Panatilihing tumatakbo ang lumang endpoint hanggang pumasa ang validation na iyon, at panatilihin ang administrative path na hindi umaasa sa bago.

Isang hangganang dapat banggitin: saklaw nito ang IPv4 client pool. Ang mga setting ng trapiko na dual-stack at IPv6 sa Client VPN ay sumusunod sa sarili nitong modelo ng addressing, kaya huwag kopyahin ang listahang ito nang hindi binabasa ang dokumentasyon para sa mode na iyon.