DNS do endpoint do AWS Client VPN: por que fixar o IP resolvido falha

Na semana passada, dig +short deu um endereço para o nome do endpoint no seu perfil do AWS Client VPN, e o túnel conectou. Esta semana o mesmo perfil fica em 'Connecting' no seu portátil enquanto a cópia intacta de um colega continua a funcionar. Nada foi bloqueado e o certificado não expirou. Alguém substituiu o nome de host do endpoint por esse endereço resolvido, e o serviço já não responde ali. O nome exportado é a parte construída para sobreviver a essa mudança.

O nome no seu perfil pode não ser o nome que é consultado

Perfis exportados do Client VPN costumam trazer remote-random-hostname. Com essa opção ativa, o cliente cria um rótulo descartável, junta-o ao nome do endpoint com um ponto e resolve o nome combinado. Um registo wildcard na zona do endpoint responde a qualquer rótulo, por isso um prefixo inventado também resolve e por isso o truque fica invisível quando tenta reproduzir a consulta à mão.

Assim, quando cola o nome do endpoint num terminal e obtém uma resposta, resolveu um nome diferente do que o cliente usa ao ligar-se. Essa discrepância não é um defeito a corrigir no perfil. O rótulo é regenerado de propósito: a opção impede que as caches guardem uma resposta antiga e nunca identifica a sua máquina nem a sua sessão.

Já encontrei o caso de compatibilidade em que um cliente ignora a opção por completo. A AWS documenta a solução: mantenha o nome real do endpoint e acrescente à frente uma cadeia aleatória mais um ponto, tratando-o como um padrão de nomenclatura e não como um valor a colar. Aplicá-lo a um cliente antigo é razoável; codificar a cadeia com prefixo como endpoint não é.

Por que uma resposta guardada não pode manter-se correta

Os endereços do endpoint do Client VPN são geridos pela AWS e mudam ao longo do tempo, como a documentação de boas práticas diz claramente. Uma resposta capturada é uma fotografia de uma resolução. Um perfil que a codifica torna-se um perfil apontado a um host desativado assim que o serviço se move, e a falha raramente parece DNS: obtém um tempo limite de ligação ou um handshake parado, por isso as pessoas perseguem rotas e certificados.

A mesma resposta em /etc/hosts herda a mesma expiração com um problema extra. Uma entrada hosts sobrevive a reinícios, reexportações e correções de 'reinstalar o cliente', por isso a falha regressa sempre que o endereço se move. Vi uma ficar semanas inofensiva e depois deixar fora de serviço todas as máquinas que a transportavam, enquanto instalações novas ligavam normalmente. Essa divisão, um grupo a falhar e outro bem na mesma conta, é a pista mais barata que vai conseguir.

Delimite bem o alcance da aleatorização. Ocorre por tentativa de ligação. Um túnel estabelecido não volta a resolver o seu endpoint, não troca de servidor a meio da sessão, e os pedidos individuais das aplicações não escolhem cada um um novo host VPN. Só a tentativa seguinte volta a resolver, por isso uma sessão que funciona toda a tarde não diz nada sobre amanhã de manhã.

O que o serviço verifica quando o túnel sobe

O Client VPN exige que o endereço a que está ligado corresponda a um endereço resolvido para o nome DNS do endpoint. Esse único requisito explica várias falhas que parecem não relacionadas: um registo DNS personalizado a apontar para outro lado, um frontend personalizado que encaminha para o endereço real do endpoint e um perfil reescrito para um endereço em bruto. A AWS documenta a combinação de registo personalizado com encaminhamento como uma falha com clientes recentes da AWS. A verificação é estreita; não é uma sentença de que todos os aliases estão proibidos.

Também não é uma regra geral sobre protocolos VPN. Um remote numérico é perfeitamente válido numa implementação normal de OpenVPN, e muitas funcionam assim. A restrição vem do arranjo gerido, não do protocolo por baixo.

O que torna o relaxamento da verificação do certificado o reflexo errado. Se um perfil falha após uma troca de endereço, desativar a verificação do servidor move o erro em vez de corrigir a resolução ou o requisito de correspondência de endereço, e deixa um cliente que confiará em qualquer coisa. Mantenha a AC exportada, a verificação do servidor e as definições de autenticação mútua exatamente como chegaram.

Listas de permissões, saída e DNS privado são três problemas separados

Uma regra de firewall que tem de permitir um destino antes de o portátil ligar diz respeito ao ouvinte exterior. Dê ao dono da rede o nome do endpoint, o transporte e a porta configurada, e depois pergunte se o controlo deles consegue seguir o comportamento DNS do serviço. Uma regra que guarda um endereço capturado é uma fotografia com uma expiração não escrita. Se o controlo só aceita destinos imutáveis, resolva essa lacuna antes do lançamento em vez de codificar uma resposta em silêncio.

Um parceiro que precisa de um endereço de origem fixo para pedidos feitos depois de o túnel estar levantado tem outro requisito: a saída. O que um site observa depende da rota da aplicação e da política de túnel dividido, não do endereço a que o cliente se ligou. O tráfego em túnel dividido pode nunca tocar na AWS.

O DNS privado dentro do túnel é uma terceira camada. O resolver entregue aos clientes responde a nomes internos após a ligação; não consegue resolver o endpoint público antes de o túnel existir. Uma falha de resolução do endpoint e uma falha de resolução de uma aplicação interna acontecem em fases diferentes, e misturá-las leva-o ao registo errado.

A família de endereços pertence à mesma lista. Uma resposta IPv4 não diz nada sobre o caminho permitido de um endpoint IPv6 ou de pilha dupla, por isso uma fotografia tirada numa família não é prova para a outra.

Verifique uma ligação sem fixar nada

Comece pelo perfil tal como foi exportado e leia o que ele pede realmente:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Depois compare três coisas: o nome do endpoint que o perfil tem, o endereço que o cliente reporta para uma nova tentativa e aquilo em que o nome resolve agora. Um nome que resolve prova apenas que o registo responde; transporte e autenticação são separados, e o endpoint não tem de responder a um ping. O registo do próprio cliente é a única fonte para o elemento do meio, por isso capture-o durante a tentativa e não depois.

Um endereço que responde hoje é prova sobre hoje; o nome é o que o serviço mantém válido. Registe a observação, envie-a a quem possui o endpoint e deixe o perfil a apontar para o nome.

Dois hábitos a abandonar: desativar as verificações de certificado para passar um handshake parado, e empilhar rótulos à frente do nome do endpoint na esperança de que um pegue. Um rótulo resolve pelo registo wildcard ou o problema está noutro lado. Se um perfil corretamente configurado continuar a falhar, envie a consulta exata e o evento de ligação, não um nome de host mais longo.

Antes de fechar: o perfil ainda transporta o nome exportado do endpoint, nenhum ficheiro hosts fixa o endereço, o remote do registo do cliente corresponde a uma resolução atual e a regra de firewall nomeia o endpoint em vez de um endereço. Esse é também o estado a entregar à pessoa seguinte.