O CIDR de cliente de AWS Client VPN non pode solaparse co rango da VPC

Un endpoint de AWS Client VPN reparte enderezos de cliente desde un pool que vostede escolle, e AWS comproba ese pool contra a rede de destino antes de crear o endpoint. A comprobación non é se unha subrede parece libre. É se o pool se solapa co rango da VPC, e a resposta é a mesma tanto se unha instancia EC2 usa hoxe eses enderezos como se non. O solapamento é unha cuestión de rangos, non de asignacións.

Percorra cinco comprobacións en orde. Detéñase na primeira que falle, porque ningún paso posterior pode reparar unha decisión anterior.

O solapamento é unha proba de rangos, non unha proba de enderezos libres

Comece polo CIDR da VPC, non pola subrede que pensa asociar. Un pool de 172.20.0.0/22 queda dentro dunha VPC de 172.20.0.0/16 e rexéitase aínda que ningunha subrede o ocupe, porque o solapamento é unha propiedade dos rangos e non das asignacións actuais. Despois engada os destinos cara aos que encamiña o endpoint: VPC emparelladas, unha pasarela de tránsito e rangos locais por unha conexión site-to-site. Calquera rango ao que un cliente poida necesitar chegar pertence á lista.

Recólllaos da conta en lugar da memoria: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", máis as entradas da táboa de rutas da subrede que pensa asociar.

O tamaño do pool decídese antes de construír

AWS acepta un pool de clientes IPv4 entre /22 e /12 en Client VPN. Unha /24 é demasiado pequena, unha /8 queda fóra do rango documentado, e ambos os erros veñen de dimensionar o pool como unha subrede de carga de traballo. Dimensiónao polos clientes simultáneos previstos máis unha marxe, e despois redondea a un prefixo permitido.

Comprobe a aritmética antes de escribila na consola, porque un prefixo mal tecleado cambia o tamaño do pool sen 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')))"

Iso imprime o número de enderezos, a lonxitude do prefixo e se o candidato choca co rango da VPC, o que é máis rápido que razoar sobre máscaras de rede ao final dunha xanela de cambios.

O resolvedor ten o seu propio papel de enderezo

O resolvedor da VPC responde no enderezo base do rango da VPC máis dous, que non está necesariamente dentro da subrede que asociou. Supoñer que o resolvedor debe vivir no pool de clientes, ou construír unha subrede arredor dese enderezo, engade obxectos sen cambiar nada. O que importa é que o endpoint leve un axuste de DNS que o cliente poida aplicar e que o resolvedor sexa alcanzable desde o túnel.

Rexistre o resolvedor, o pool de clientes e a subrede asociada como tres elementos separados no plan de enderezamento. Fallan de forma independente, e que un sexa correcto non di nada sobre os outros dous.

Catro campos que fixa ao crear

O CIDR IPv4 do cliente queda fixado ao crear. Cambiar o servidor DNS, engadir unha asociación, substituír o grupo de seguridade, editar regras de autorización ou alterar rutas de split-tunnel son edicións ordinarias, e ningunha delas renomea o pool. Esa asimetría é a razón pola que isto merece unha revisión: os axustes baratos son os que quererá cambiar despois, e o caro é o que fixa primeiro. Lea a descrición do endpoint antes de planificar unha xanela de cambios.

Inspeccione o endpoint despregado antes de supoñer unha reconstrución. aws ec2 describe-client-vpn-endpoints devolve o pool, o DNS, o indicador de split-tunnel e as asociacións nunha soa resposta, o que normalmente abonda para descartar unha reconstrución.

Substitúa o endpoint en lugar de parchealo

Un endpoint novo é un endpoint novo, non unha migración. As sesións existentes non se trasladan a el, os perfís de cliente apuntan a outro nome, e cada axuste que daba por feito debe recrearse: certificado do servidor, autenticación, asociacións, rutas, grupos de autorización e rexistro. Valide cun cliente contra un servizo privado obrigatorio e contra un destino que se debe denegar, e despois amplíe o acceso. Todo o que se salte convértese máis tarde nun tícket de soporte.

Manteña o endpoint antigo en marcha ata que pase esa validación, e conserve unha vía administrativa que non dependa do novo.

Un límite que cómpre enunciar: isto cobre o pool de clientes IPv4. Os axustes de tráfico dual-stack e IPv6 en Client VPN seguen o seu propio modelo de enderezamento, así que non copie esta lista sen ler a documentación dese modo.