Il CIDR client di AWS Client VPN non può sovrapporsi all'intervallo della VPC

Un endpoint di AWS Client VPN distribuisce indirizzi client da un pool che scegli tu, e AWS controlla quel pool rispetto alla rete di destinazione prima di creare l'endpoint. Il controllo non riguarda se una subnet sembra libera. Riguarda se il pool si sovrappone all'intervallo della VPC, e la risposta è la stessa sia che un'istanza EC2 usi oggi quegli indirizzi sia che no. La sovrapposizione è una questione di intervalli, non di assegnazioni.

Percorri cinque controlli in ordine. Fermati al primo che fallisce, perché nessun passaggio successivo può riparare una decisione precedente.

La sovrapposizione è un test di intervalli, non un test di indirizzi liberi

Parti dal CIDR della VPC, non dalla subnet che pensi di associare. Un pool di 172.20.0.0/22 si trova dentro una VPC di 172.20.0.0/16 e viene rifiutato anche quando nessuna subnet lo occupa, perché la sovrapposizione è una proprietà degli intervalli e non delle assegnazioni attuali. Poi aggiungi le destinazioni verso cui l'endpoint instrada: VPC in peering, un transit gateway e intervalli on-premises tramite una connessione site-to-site. Qualsiasi intervallo che un client possa aver bisogno di raggiungere appartiene all'elenco.

Raccoglili dall'account invece che dalla memoria: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", più le voci della tabella di routing per la subnet che pensi di associare.

La dimensione del pool si decide prima di costruire

AWS accetta un pool client IPv4 tra /22 e /12 su Client VPN. Un /24 è troppo piccolo, un /8 è fuori dall'intervallo documentato, ed entrambi gli errori derivano dal dimensionare il pool come una subnet di carico di lavoro. Dimensionalo in base ai client simultanei attesi più un margine, poi arrotonda a un prefisso consentito.

Verifica l'aritmetica prima di digitarla nella console, perché un prefisso digitato male cambia la dimensione del pool senza alcun avviso:

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

Stampa il numero di indirizzi, la lunghezza del prefisso e se il candidato collide con l'intervallo della VPC, il che è più rapido che ragionare sulle netmask alla fine di una finestra di cambiamento.

Il resolver ha un proprio ruolo di indirizzo

Il resolver della VPC risponde all'indirizzo di base dell'intervallo della VPC più due, che non è necessariamente dentro la subnet che hai associato. Presumere che il resolver debba vivere nel pool client, o costruire una subnet attorno a quell'indirizzo, aggiunge oggetti senza cambiare nulla. Ciò che conta è che l'endpoint porti un'impostazione DNS che il client possa applicare e che il resolver sia raggiungibile dal tunnel.

Registra il resolver, il pool client e la subnet associata come tre voci separate nel piano degli indirizzi. Falliscono in modo indipendente, e il fatto che uno sia corretto non dice nulla sugli altri due.

Quattro campi su cui ti impegni alla creazione

Il CIDR IPv4 del client è fissato alla creazione. Cambiare il server DNS, aggiungere un'associazione, sostituire il gruppo di sicurezza, modificare le regole di autorizzazione o alterare le rotte split-tunnel sono tutte modifiche ordinarie, e nessuna di esse rinomina il pool. Questa asimmetria è il motivo per cui la cosa merita una revisione: le impostazioni economiche sono quelle che vorrai cambiare dopo, e quella costosa è quella su cui ti impegni per prima. Leggi la descrizione dell'endpoint prima di pianificare una finestra di cambiamento.

Ispeziona l'endpoint distribuito prima di presumere una ricostruzione. aws ec2 describe-client-vpn-endpoints restituisce pool, DNS, flag split-tunnel e associazioni in un'unica risposta, che di solito basta a escludere una ricostruzione.

Sostituisci l'endpoint invece di rattopparlo

Un nuovo endpoint è un nuovo endpoint, non una migrazione. Le sessioni esistenti non vi si trasferiscono, i profili client puntano a un altro nome, e ogni impostazione che dai per scontata deve essere ricreata: certificato server, autenticazione, associazioni, rotte, gruppi di autorizzazione, registrazione. Convalida con un client contro un servizio privato obbligatorio e contro una destinazione che deve essere negata, poi amplia l'accesso. Tutto ciò che salti diventa un ticket di supporto più tardi.

Mantieni in funzione il vecchio endpoint finché quella convalida non passa, e conserva un percorso amministrativo che non dipenda dal nuovo.

Un limite che vale la pena enunciare: questo copre il pool client IPv4. Le impostazioni di traffico dual-stack e IPv6 su Client VPN seguono il proprio modello di indirizzamento, quindi non copiare questo elenco senza leggere la documentazione di quella modalità.