DNS no AWS Client VPN: use o resolver da VPC, não a sub-rede

O endpoint está em 10.0.8.0/24, então o resolver deve ser 10.0.8.2. Esse é o raciocínio que mais ouço, e está errado duas vezes. O Route 53 Resolver responde no intervalo IPv4 principal da VPC mais dois, que para uma VPC de 10.0.0.0/16 é 10.0.0.2, qualquer que seja a sub-rede usada pelo endpoint. O segundo erro é mais silencioso: colocar o endereço certo no endpoint não significa que o sistema operacional do cliente alguma vez pergunte algo a ele. Os dois erros produzem o mesmo sintoma: a resolução de nomes funciona em alguns clientes e falha em outros.

O mito começa na associação da sub-rede

A associação trata de onde ficam as interfaces de rede elásticas das conexões de clientes, não de qual endereço de resolver existe. As sub-redes do endpoint dão aos clientes um endereço dentro da VPC, e nenhuma delas carrega o próprio resolver.

Ao separar essas duas ideias, a aritmética deixa de ser misteriosa e o diagnóstico passa para o cliente, onde a maioria desses casos realmente termina.

Calcule o endereço a partir do intervalo principal da VPC

Pegue o CIDR IPv4 principal da VPC e some dois ao endereço de rede. 10.0.0.0/16 dá 10.0.0.2, 172.31.0.0/16 dá 172.31.0.2, e uma VPC com intervalo secundário mantém o resolver no principal. Uma sub-rede de 10.0.8.0/24 dentro dessa VPC não o move. Anote o endereço ao lado do ID da VPC antes de tocar no endpoint, porque o número é propriedade da VPC e não da conexão.

A VPC também responde no endereço link-local 169.254.169.253. Esse endereço é alcançável de dentro da VPC, mas não é um destino roteado de uso geral para um laptop na outra ponta de um túnel.

Então há dois endereços de resolver válidos, e nenhum deles é a sub-rede mais dois.

O que a configuração do endpoint faz e o que não faz

O endpoint do Client VPN tem campos de servidor DNS, e onde o console oferece uma opção de resolver da VPC ele preenche a mesma ideia. Defini-los muda o que o serviço entrega aos clientes durante o estabelecimento da conexão. Não muda o que um cliente OpenVPN não gerenciado faz com esse valor, porque o cliente ainda precisa aplicá-lo ao sistema operacional. Dessa lacuna vem «funciona no meu Mac mas não na máquina Linux».

No Linux, a integração do resolver pertence ao gerenciador de conexões e não ao usuário. Editar /etc/resolv.conf à mão prova que o endereço funciona por uma sessão e depois desaparece ao reconectar, por isso tantos casos corrigidos voltam na manhã seguinte.

Verifique o resolver ativo no cliente depois de conectar, não a página de configuração do endpoint.

O tunneling dividido pode anular um resolver correto

Com tunneling dividido, só as rotas empurradas para o túnel são usadas. Se o endereço do resolver não for coberto por uma rota, a consulta sai pela interface local e é respondida pelo seu roteador doméstico. O endereço no endpoint continua correto e a consulta continua falhando. Adicione a rota do resolver e teste de novo.

Intervalos locais sobrepostos produzem o mesmo resultado de forma mais desagradável: a consulta recebe resposta, mas do servidor errado.

Não abra grupos de segurança para o endereço do Amazon DNS

O instinto quando as consultas expiram é adicionar uma regra que permita UDP 53 para o endereço do resolver. A AWS documenta que grupos de segurança e ACLs de rede não filtram o tráfego do Amazon DNS como filtram o tráfego para uma instância DNS própria. Abrir essas regras não muda nada para o resolver da VPC e amplia o perímetro sem motivo. Um resolver que você mesmo opera é outro caso e realmente precisa das próprias regras.

Se os dois aparecem no seu projeto, verifique para qual o cliente realmente aponta antes de editar qualquer regra.

Verifique o caminho e depois meça outra coisa

Resolva um nome público, resolva um nome privado registrado em uma zona hospedada privada associada à VPC e leia entre eles o resolver ativo do cliente. Essa sequência separa «o endereço do resolver está errado» de «a zona não está associada» e de «o cliente ignorou a configuração». Cada um tem uma correção diferente, e nenhum é problema de throughput.

Uma consulta bem-sucedida não diz nada sobre velocidade de transferência sustentada, então mantenha essas duas conversas separadas ao reportar.