O CIDR de cliente do AWS Client VPN não pode sobrepor o intervalo da VPC

Um endpoint do AWS Client VPN distribui endereços de cliente de um pool que você escolhe, e a AWS verifica esse pool contra a rede de destino antes de criar o endpoint. A verificação não é se uma sub-rede parece livre. É se o pool sobrepõe o intervalo da VPC, e a resposta é a mesma quer uma instância EC2 use esses endereços hoje quer não. Sobreposição é uma questão de intervalos, não de atribuições.

Percorra cinco verificações em ordem. Pare na primeira que falhar, porque nenhum passo posterior pode reparar uma decisão anterior.

Sobreposição é um teste de intervalos, não um teste de endereços livres

Comece pelo CIDR da VPC, não pela sub-rede que pretende associar. Um pool de 172.20.0.0/22 fica dentro de uma VPC de 172.20.0.0/16 e é rejeitado mesmo quando nenhuma sub-rede o ocupa, porque a sobreposição é uma propriedade dos intervalos e não das atribuições atuais. Depois acrescente os destinos para os quais o endpoint encaminha: VPCs emparelhadas, um gateway de trânsito e intervalos locais por uma conexão site-to-site. Qualquer intervalo que um cliente possa precisar alcançar pertence à lista.

Recolha-os da conta em vez da memória: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", mais as entradas da tabela de rotas da sub-rede que pretende associar.

O tamanho do pool é decidido antes de construir

A AWS aceita um pool de clientes IPv4 entre /22 e /12 no Client VPN. Um /24 é pequeno demais, um /8 está fora do intervalo documentado, e ambos os erros vêm de dimensionar o pool como uma sub-rede de carga de trabalho. Dimensione-o pelos clientes simultâneos esperados mais uma margem, e depois arredonde para um prefixo permitido.

Verifique a aritmética antes de a digitar no console, porque um prefixo digitado errado altera o tamanho do pool sem qualquer 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')))"

Isso imprime o número de endereços, o comprimento do prefixo e se o candidato colide com o intervalo da VPC, o que é mais rápido do que raciocinar sobre máscaras de rede no fim de uma janela de mudança.

O resolver tem o seu próprio papel de endereço

O resolver da VPC responde no endereço base do intervalo da VPC mais dois, que não está necessariamente dentro da sub-rede associada. Assumir que o resolver tem de viver no pool de clientes, ou construir uma sub-rede em torno desse endereço, acrescenta objetos sem mudar nada. O que importa é que o endpoint traga uma definição de DNS que o cliente possa aplicar e que o resolver seja alcançável a partir do túnel.

Registe o resolver, o pool de clientes e a sub-rede associada como três itens separados no plano de endereçamento. Falham de forma independente, e o facto de um estar correto não diz nada sobre os outros dois.

Quatro campos que fixa na criação

O CIDR IPv4 do cliente é fixo na criação. Alterar o servidor DNS, adicionar uma associação, trocar o grupo de segurança, editar regras de autorização ou mudar rotas split-tunnel são edições comuns, e nenhuma delas renomeia o pool. Essa assimetria é a razão pela qual isto merece uma revisão: as definições baratas são as que vai querer mudar mais tarde, e a cara é a que fixa primeiro. Leia a descrição do endpoint antes de planear uma janela de mudança.

Inspecione o endpoint implementado antes de assumir uma reconstrução. aws ec2 describe-client-vpn-endpoints devolve o pool, o DNS, o indicador split-tunnel e as associações numa única resposta, o que normalmente basta para excluir uma reconstrução.

Substitua o endpoint em vez de o remendar

Um endpoint novo é um endpoint novo, não uma migração. As sessões existentes não passam para ele, os perfis de cliente apontam para outro nome, e cada definição que tomava como garantida tem de ser recriada: certificado do servidor, autenticação, associações, rotas, grupos de autorização e registo. Valide com um cliente contra um serviço privado obrigatório e contra um destino que tem de ser negado, e depois alargue o acesso. Tudo o que saltar torna-se um pedido de suporte mais tarde.

Mantenha o endpoint antigo em funcionamento até essa validação passar, e conserve um caminho administrativo que não dependa do novo.

Um limite que vale a pena enunciar: isto cobre o pool de clientes IPv4. As definições de tráfego dual-stack e IPv6 no Client VPN seguem o seu próprio modelo de endereçamento, por isso não copie esta lista sem ler a documentação desse modo.