El CIDR de cliente de AWS Client VPN no puede solaparse con el rango de la VPC

Un endpoint de AWS Client VPN reparte direcciones de cliente desde un pool que usted elige, y AWS comprueba ese pool contra la red de destino antes de crear el endpoint. La comprobación no es si una subred parece libre. Es si el pool se solapa con el rango de la VPC, y la respuesta es la misma tanto si una instancia EC2 usa hoy esas direcciones como si no. El solapamiento es una cuestión de rangos, no de asignaciones.

Recorra cinco comprobaciones en orden. Deténgase en la primera que falle, porque ningún paso posterior puede reparar una decisión anterior.

El solapamiento es una prueba de rangos, no una prueba de direcciones libres

Empiece por el CIDR de la VPC, no por la subred que piensa asociar. Un pool de 172.20.0.0/22 queda dentro de una VPC de 172.20.0.0/16 y se rechaza aunque ninguna subred lo ocupe, porque el solapamiento es una propiedad de los rangos y no de las asignaciones actuales. Después añada los destinos hacia los que enruta el endpoint: VPC emparejadas, una pasarela de tránsito y rangos locales por una conexión site-to-site. Cualquier rango al que un cliente pueda necesitar llegar pertenece a la lista.

Recójalos de la cuenta en lugar de la memoria: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", más las entradas de la tabla de rutas de la subred que piensa asociar.

El tamaño del pool se decide antes de construir

AWS acepta un pool de clientes IPv4 entre /22 y /12 en Client VPN. Una /24 es demasiado pequeña, una /8 queda fuera del rango documentado, y ambos errores vienen de dimensionar el pool como una subred de carga de trabajo. Dimensiónelo por los clientes concurrentes previstos más un margen, y luego redondee a un prefijo permitido.

Compruebe la aritmética antes de escribirla en la consola, porque un prefijo mal tecleado cambia el tamaño del pool sin ningún aviso:

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

Eso imprime el número de direcciones, la longitud del prefijo y si el candidato choca con el rango de la VPC, lo que es más rápido que razonar sobre máscaras de red al final de una ventana de cambios.

El resolutor tiene su propio papel de dirección

El resolutor de la VPC responde en la dirección base del rango de la VPC más dos, que no está necesariamente dentro de la subred que asoció. Suponer que el resolutor debe vivir en el pool de clientes, o construir una subred alrededor de esa dirección, añade objetos sin cambiar nada. Lo que importa es que el endpoint lleve un ajuste de DNS que el cliente pueda aplicar y que el resolutor sea alcanzable desde el túnel.

Registre el resolutor, el pool de clientes y la subred asociada como tres elementos separados en el plan de direccionamiento. Fallan de forma independiente, y que uno sea correcto no dice nada sobre los otros dos.

Cuatro campos que fija al crear el endpoint

El CIDR IPv4 del cliente queda fijado al crear. Cambiar el servidor DNS, añadir una asociación, sustituir el grupo de seguridad, editar reglas de autorización o alterar rutas de split-tunnel son ediciones ordinarias, y ninguna de ellas renombra el pool. Esa asimetría es la razón por la que esto merece una revisión: los ajustes baratos son los que querrá cambiar después, y el caro es el que fija primero. Lea la descripción del endpoint antes de planificar una ventana de cambios.

Inspeccione el endpoint desplegado antes de suponer una reconstrucción. aws ec2 describe-client-vpn-endpoints devuelve el pool, el DNS, el indicador de split-tunnel y las asociaciones en una sola respuesta, lo que suele bastar para descartar una reconstrucción.

Sustituya el endpoint en lugar de parchearlo

Un endpoint nuevo es un endpoint nuevo, no una migración. Las sesiones existentes no se trasladan a él, los perfiles de cliente apuntan a otro nombre, y cada ajuste que daba por hecho debe recrearse: certificado del servidor, autenticación, asociaciones, rutas, grupos de autorización y registro. Valide con un cliente contra un servicio privado obligatorio y contra un destino que deba denegarse, y luego amplíe el acceso. Todo lo que se salte se convierte más tarde en un tique de soporte.

Mantenga el endpoint antiguo en marcha hasta que pase esa validación, y conserve una vía administrativa que no dependa del nuevo.

Un límite que conviene enunciar: esto cubre el pool de clientes IPv4. Los ajustes de tráfico dual-stack e IPv6 en Client VPN siguen su propio modelo de direccionamiento, así que no copie esta lista sin leer la documentación de ese modo.