CIDR-ul de client din AWS Client VPN nu poate suprapune intervalul VPC

Un endpoint AWS Client VPN distribuie adrese de client dintr-un pool pe care îl alegi, iar AWS verifică acel pool față de rețeaua țintă înainte de a crea endpoint-ul. Verificarea nu este dacă o subrețea pare liberă. Este dacă pool-ul se suprapune cu intervalul VPC, iar răspunsul este același indiferent dacă o instanță EC2 folosește astăzi acele adrese. Suprapunerea este o chestiune de intervale, nu de alocări.

Parcurge cinci verificări în ordine. Oprește-te la prima care eșuează, pentru că niciun pas ulterior nu poate repara o decizie anterioară.

Suprapunerea este un test de intervale, nu un test de adrese libere

Pornește de la CIDR-ul VPC, nu de la subrețeaua pe care intenționezi să o asociezi. Un pool de 172.20.0.0/22 se află în interiorul unui VPC de 172.20.0.0/16 și este respins chiar și când nicio subrețea nu îl ocupă, pentru că suprapunerea este o proprietate a intervalelor, nu a alocărilor curente. Apoi adaugă destinațiile către care endpoint-ul rutează: VPC-uri peer, un transit gateway și intervale locale printr-o conexiune site-to-site. Orice interval la care un client ar putea avea nevoie să ajungă aparține listei.

Colectează-le din cont, nu din memorie: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus intrările din tabelul de rutare pentru subrețeaua pe care intenționezi să o asociezi.

Dimensiunea pool-ului se decide înainte de construcție

AWS acceptă un pool de clienți IPv4 între /22 și /12 pe Client VPN. Un /24 este prea mic, un /8 este în afara intervalului documentat, iar ambele greșeli provin din dimensionarea pool-ului ca o subrețea de lucru. Dimensionează-l după clienții concurenți așteptați plus o marjă, apoi rotunjește la un prefix permis.

Verifică aritmetica înainte de a o tasta în consolă, pentru că un prefix tastat greșit schimbă dimensiunea pool-ului fără niciun avertisment:

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

Aceasta tipărește numărul de adrese, lungimea prefixului și dacă candidatul se ciocnește cu intervalul VPC, ceea ce este mai rapid decât să raționezi despre măști de rețea la sfârșitul unei ferestre de schimbare.

Resolverul are propriul rol de adresă

Resolverul VPC răspunde la adresa de bază a intervalului VPC plus doi, care nu este neapărat în interiorul subrețelei asociate. Presupunerea că resolverul trebuie să locuiască în pool-ul de clienți, sau construirea unei subrețele în jurul acelei adrese, adaugă obiecte fără a schimba nimic. Contează ca endpoint-ul să poarte o setare DNS pe care clientul o poate aplica și ca resolverul să fie accesibil din tunel.

Înregistrează resolverul, pool-ul de clienți și subrețeaua asociată ca trei elemente separate în planul de adresare. Ele eșuează independent, iar faptul că unul este corect nu spune nimic despre celelalte două.

Patru câmpuri pe care le fixezi la creare

CIDR-ul IPv4 al clientului este fix la creare. Schimbarea serverului DNS, adăugarea unei asocieri, înlocuirea grupului de securitate, editarea regulilor de autorizare sau modificarea rutelor split-tunnel sunt toate editări obișnuite și niciuna nu redenumește pool-ul. Această asimetrie este motivul pentru care lucrul acesta merită o revizuire: setările ieftine sunt cele pe care vei vrea să le schimbi mai târziu, iar cea scumpă este cea pe care o fixezi prima. Citește descrierea endpoint-ului înainte de a planifica o fereastră de schimbare.

Inspectează endpoint-ul implementat înainte de a presupune o reconstrucție. aws ec2 describe-client-vpn-endpoints returnează pool-ul, DNS-ul, indicatorul split-tunnel și asocierile într-un singur răspuns, ceea ce de obicei este suficient pentru a exclude o reconstrucție.

Înlocuiește endpoint-ul în loc să-l peticesti

Un endpoint nou este un endpoint nou, nu o migrare. Sesiunile existente nu se mută pe el, profilurile de client indică un alt nume, iar fiecare setare pe care o considerai de la sine înțeleasă trebuie recreată: certificatul de server, autentificarea, asocierile, rutele, grupurile de autorizare, jurnalizarea. Validează cu un singur client împotriva unui serviciu privat obligatoriu și împotriva unei destinații care trebuie refuzată, apoi lărgește accesul. Orice sari va deveni mai târziu un tichet de suport.

Ține endpoint-ul vechi în funcțiune până când trece acea validare și păstrează o cale administrativă care nu depinde de cel nou.

O limită care merită menționată: acest lucru acoperă pool-ul de clienți IPv4. Setările de trafic dual-stack și IPv6 pe Client VPN urmează propriul model de adresare, așa că nu copia această listă fără a citi documentația pentru acel mod.