La klienta CIDR de AWS Client VPN ne rajtas interkovri la VPC-gamon

Finpunkto de AWS Client VPN disdonas klientajn adresojn el poolo, kiun vi elektas, kaj AWS kontrolas tiun poolon kontraŭ la cela reto antaŭ ol ĝi kreas la finpunkton. La kontrolo ne temas pri tio, ĉu subreto aspektas libera. Ĝi temas pri tio, ĉu la poolo interkovras la VPC-gamon, kaj la respondo samas sendepende de tio, ĉu EC2-maŝino hazarde uzas tiujn adresojn hodiaŭ. Interkovro estas demando pri gamoj, ne pri atribuoj.

Trapasu kvin kontrolojn laŭvice. Haltu ĉe la unua, kiu fiaskas, ĉar neniu posta paŝo povas ripari pli frue faritan decidon.

Interkovro estas testado de gamoj, ne testado de liberaj adresoj

Komencu de la CIDR de la VPC, ne de la subreto, kiun vi planas kunligi. Poolo de 172.20.0.0/22 troviĝas ene de VPC de 172.20.0.0/16 kaj estas rifuzata eĉ kiam neniu subreto okupas ĝin, ĉar interkovro estas eco de la gamoj, ne de la nunaj atribuoj. Poste aldonu la celojn, al kiuj la finpunkto enkursigas: kunligitaj VPC-oj, transit gateway, lokaj gamoj tra site-to-site-konekto. Ĉiu gamo, kiun kliento eble bezonas atingi, apartenas al la listo.

Kolektu ilin el la konto anstataŭ el la memoro: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus la eniroj de la enkursiga tabelo por la subreto, kiun vi intencas kunligi.

La grandeco de la poolo decidiĝas antaŭ la konstruado

AWS akceptas IPv4-klientan poolon inter /22 kaj /12 en Client VPN. /24 estas tro malgranda, /8 estas ekster la dokumentita gamo, kaj ambaŭ eraroj venas de taksado de la poolo kiel labortempa subreto. Grandumu ĝin laŭ la atendataj samtempaj klientoj plus rezervo, poste rondigu al permesita prefikso.

Kontrolu la aritmetikon antaŭ ol tajpi ĝin en la konzolon, ĉar mistajpita prefikso ŝanĝas la grandecon de la poolo sen ajna averto:

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

Tio presas la nombron de adresoj, la longecon de la prefikso kaj ĉu la kandidato kolizias kun la VPC-gamo, kio estas pli rapida ol pripensi retmaskojn ĉe la fino de ŝanĝofenestro.

La solvilo havas propran adresan rolon

La VPC-solvilo respondas ĉe la baza adreso de la VPC-gamo plus du, kiu ne nepre troviĝas ene de la subreto, kiun vi kunligis. Supozi, ke la solvilo devas loĝi en la klienta poolo, aŭ konstrui subreton ĉirkaŭ tiu adreso, aldonas objektojn sen ŝanĝi ion. Gravas, ke la finpunkto portas DNS-agordon, kiun la kliento povas apliki, kaj ke la solvilo estas atingebla el la tunelo.

Notu la solvilon, la klientan poolon kaj la kunligitan subreton kiel tri apartajn erojn en la adresa plano. Ili fiaskas sendepende, kaj tio, ke unu estas ĝusta, diras nenion pri la aliaj du.

Kvar kampoj, al kiuj vi devontigas vin ĉe kreado

La klienta IPv4-CIDR estas fiksita ĉe kreado. Ŝanĝi la DNS-servilon, aldoni kunligaĵon, anstataŭigi la sekurecan grupon, redakti rajtigajn regulojn aŭ ŝanĝi split-tunnel-vojojn estas ĉiuj ordinaraj redaktoj, kaj neniu el ili renomas la poolon. Tiu malsimetrio estas la kialo, kial tio meritas revizion: la malmultekostaj agordoj estas tiuj, kiujn vi volos ŝanĝi poste, kaj la multekosta estas tiu, al kiu vi devontigas vin unue. Legu la priskribon de la finpunkto antaŭ ol plani ŝanĝofenestron.

Inspektu la deplojitan finpunkton antaŭ ol supozi rekonstruon. aws ec2 describe-client-vpn-endpoints redonas la poolon, DNS, la split-tunnel-flagon kaj la kunligaĵojn en unu respondo, kio kutime sufiĉas por ekskludi rekonstruon.

Anstataŭigu la finpunkton anstataŭ fliki ĝin

Nova finpunkto estas nova finpunkto, ne migrado. Ekzistantaj sesioj ne translokiĝas al ĝi, klientaj profiloj montras al alia nomo, kaj ĉiu agordo, kiun vi prenis kiel memkompreneblan, devas esti rekreada: servila atestilo, aŭtentikigo, kunligaĵoj, vojoj, rajtigaj grupoj, protokolado. Validigu per unu kliento kontraŭ postulata privata servo kaj kontraŭ celo, kiu devas esti rifuzata, poste vastigu aliron. Ĉio, kion vi preterlasas, fariĝas subtena bileto poste.

Lasu la malnovan finpunkton funkcii ĝis tiu validigo pasas, kaj konservu administran vojon, kiu ne dependas de la nova.

Unu limo indas mencii: ĉi tio kovras la IPv4-klientan poolon. Agordoj de dual-stack kaj IPv6-trafiko en Client VPN sekvas sian propran adresan modelon, do ne kopiu ĉi tiun liston sen legi la dokumentaron por tiu reĝimo.