Le CIDR client d'AWS Client VPN ne peut pas chevaucher la plage du VPC

Un point de terminaison AWS Client VPN distribue des adresses client depuis un pool que vous choisissez, et AWS vérifie ce pool par rapport au réseau cible avant de créer le point de terminaison. La vérification ne porte pas sur le fait qu'un sous-réseau paraisse libre. Elle porte sur le fait que le pool chevauche la plage du VPC, et la réponse est la même qu'une instance EC2 utilise ou non ces adresses aujourd'hui. Le chevauchement est une question de plages, pas d'attributions.

Parcourez cinq vérifications dans l'ordre. Arrêtez-vous à la première qui échoue, car aucune étape ultérieure ne peut réparer une décision antérieure.

Le chevauchement est un test de plages, pas un test d'adresses libres

Partez du CIDR du VPC, pas du sous-réseau que vous comptez associer. Un pool de 172.20.0.0/22 se situe dans un VPC de 172.20.0.0/16 et est rejeté même si aucun sous-réseau ne l'occupe, car le chevauchement est une propriété des plages et non des attributions en cours. Ajoutez ensuite les destinations vers lesquelles le point de terminaison route : VPC appairés, une passerelle de transit et des plages locales via une connexion site-to-site. Toute plage qu'un client peut avoir besoin d'atteindre appartient à la liste.

Collectez-les depuis le compte plutôt que de mémoire : aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus les entrées de table de routage du sous-réseau que vous comptez associer.

La taille du pool se décide avant la construction

AWS accepte un pool client IPv4 entre /22 et /12 sur Client VPN. Un /24 est trop petit, un /8 sort de la plage documentée, et les deux erreurs viennent de dimensionner le pool comme un sous-réseau de charge de travail. Dimensionnez-le selon les clients simultanés attendus plus une marge, puis arrondissez à un préfixe autorisé.

Vérifiez l'arithmétique avant de la saisir dans la console, car un préfixe mal tapé change la taille du pool sans aucun avertissement :

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

Cela affiche le nombre d'adresses, la longueur du préfixe et si le candidat entre en collision avec la plage du VPC, ce qui est plus rapide que de raisonner sur les masques de réseau à la fin d'une fenêtre de changement.

Le résolveur a son propre rôle d'adresse

Le résolveur du VPC répond à l'adresse de base de la plage du VPC plus deux, qui n'est pas forcément dans le sous-réseau que vous avez associé. Supposer que le résolveur doit vivre dans le pool client, ou construire un sous-réseau autour de cette adresse, ajoute des objets sans rien changer. Ce qui compte, c'est que le point de terminaison porte un réglage DNS que le client peut appliquer et que le résolveur soit joignable depuis le tunnel.

Enregistrez le résolveur, le pool client et le sous-réseau associé comme trois éléments distincts dans le plan d'adressage. Ils échouent indépendamment, et le fait que l'un soit correct ne dit rien des deux autres.

Quatre champs sur lesquels vous vous engagez à la création

Le CIDR IPv4 du client est figé à la création. Changer le serveur DNS, ajouter une association, remplacer le groupe de sécurité, modifier les règles d'autorisation ou altérer les routes split-tunnel sont toutes des modifications ordinaires, et aucune ne renomme le pool. Cette asymétrie est la raison pour laquelle cela mérite une revue : les réglages bon marché sont ceux que vous voudrez changer plus tard, et le coûteux est celui sur lequel vous vous engagez en premier. Lisez la description du point de terminaison avant de planifier une fenêtre de changement.

Inspectez le point de terminaison déployé avant de supposer une reconstruction. aws ec2 describe-client-vpn-endpoints renvoie le pool, le DNS, l'indicateur split-tunnel et les associations en une seule réponse, ce qui suffit généralement à écarter une reconstruction.

Remplacez le point de terminaison au lieu de le rapiécer

Un nouveau point de terminaison est un nouveau point de terminaison, pas une migration. Les sessions existantes ne basculent pas dessus, les profils client pointent vers un autre nom, et chaque réglage que vous teniez pour acquis doit être recréé : certificat serveur, authentification, associations, routes, groupes d'autorisation, journalisation. Validez avec un client contre un service privé obligatoire et contre une destination qui doit être refusée, puis élargissez l'accès. Tout ce que vous omettez devient un ticket de support plus tard.

Gardez l'ancien point de terminaison en service jusqu'à ce que cette validation passe, et conservez un chemin administratif qui ne dépend pas du nouveau.

Une limite qu'il vaut la peine d'énoncer : ceci couvre le pool client IPv4. Les réglages de trafic dual-stack et IPv6 sur Client VPN suivent leur propre modèle d'adressage, donc ne recopiez pas cette liste sans lire la documentation de ce mode.