DNS do endpoint de AWS Client VPN: por que falla fixar o IP resolto

A semana pasada dig +short deulle un enderezo para o nome do endpoint no seu perfil de AWS Client VPN, e o túnel conectou. Esta semana o mesmo perfil queda en 'Connecting' no seu portátil mentres a copia intacta dun compañeiro segue funcionando. Non se bloqueou nada e o certificado non caducou. Alguén substituíu o nome de host do endpoint por ese enderezo resolto, e o servizo xa non responde alí. O nome exportado é a parte deseñada para sobrevivir a ese cambio.

O nome do seu perfil pode non ser o nome que se consulta

Os perfís exportados de Client VPN adoitan incluír remote-random-hostname. Con esa opción activada, o cliente crea unha etiqueta dun só uso, únea ao nome do endpoint cun punto e resolve o nome combinado. Un rexistro comodín na zona do endpoint responde a calquera etiqueta, por iso un prefixo inventado tamén se resolve e por iso o truco pasa desapercibido cando intenta reproducir a consulta á man.

Así que cando pega o nome do endpoint nun terminal e obtén unha resposta, resolveu un nome distinto do que usa o cliente ao conectarse. Esa discrepancia non é un defecto que corrixir no perfil. A etiqueta rexenérase a propósito: a opción impide que as cachés retenñan unha resposta obsoleta e nunca identifica a súa máquina nin a súa sesión.

Atopeime co caso de compatibilidade no que un cliente ignora a opción por completo. AWS documenta a solución: conserve o nome real do endpoint e antepoña unha cadea aleatoria máis un punto, tratándoo como un patrón de nomes e non como un valor que pegar. Aplicalo a un cliente antigo é razoable; codificar a cadea con prefixo como endpoint non o é.

Por que unha resposta gardada non pode seguir sendo correcta

AWS xestiona os enderezos do endpoint de Client VPN e cambian co tempo, o que a documentación de boas prácticas di claramente. Unha resposta capturada é unha instantánea dunha resolución. Un perfil que a codifica convértese nun perfil apuntado a un host dado de baixa en canto o servizo se move, e o fallo raramente parece DNS: obtén un tempo de espera de conexión ou un handshake atascado, así que a xente persegue rutas e certificados.

A mesma resposta en /etc/hosts herda a mesma caducidade cun problema extra. Unha entrada hosts sobrevive a reinicios, reexportacións e arranxos de 'reinstala o cliente', así que o fallo volve cada vez que o enderezo se move. Vin unha pasar semanas inofensiva e despois deixar fóra de xogo todas as máquinas que a levaban mentres as instalacións novas conectaban con normalidade. Esa división, un grupo fallando e outro ben na mesma conta, é a pista máis barata que vai obter.

Delimite ben o alcance da aleatorización. Ocorre por intento de conexión. Un túnel establecido non volve resolver o seu endpoint, non cambia de servidor a metade de sesión e as peticións individuais das aplicacións non elixen cada unha un host VPN novo. Só o seguinte intento volve resolver, por iso unha sesión que funciona toda a tarde non di nada sobre mañá pola mañá.

Que comproba o servizo cando sobe o túnel

Client VPN esixe que o enderezo ao que está conectado coincida cun enderezo resolto para o nome DNS do endpoint. Ese único requisito explica varios fallos que parecen non relacionados: un rexistro DNS personalizado que apunta a outro sitio, un frontend personalizado que reenvía ao enderezo real do endpoint e un perfil reescrito a un enderezo cru. AWS documenta a combinación de rexistro personalizado e reenvío como un fallo con clientes recentes de AWS. A comprobación é estreita; non é unha sentenza de que todo alias estea prohibido.

Tampouco é unha regra xeral sobre protocolos VPN. Un remote numérico é perfectamente válido en un despregamento normal de OpenVPN, e moitos funcionan así. A restrición vén do arranxo xestionado, non do protocolo que hai debaixo.

O que converte relaxar a verificación do certificado no reflexo equivocado. Se un perfil falla tras un cambio de enderezo, desactivar a verificación do servidor traslada o erro en lugar de arranxar a resolución ou o requisito de coincidencia de enderezo, e deixa un cliente que confiará en calquera cousa. Manteña o CA exportado, a verificación do servidor e os axustes de autenticación mutua exactamente como chegaron.

Listas de permitidos, saída e DNS privado son tres problemas separados

Unha regra de firewall que debe permitir un destino antes de que un portátil se conecte ten que ver co receptor exterior. Dea ao propietario da rede o nome do endpoint, o transporte e o porto configurado, e logo pregunte se o seu control pode seguir o comportamento DNS do servizo. Unha regra que retén un enderezo capturado é unha instantánea cunha caducidade non escrita. Se o control só acepta destinos inmutables, resolva ese oco antes do despregamento en lugar de codificar unha resposta en silencio.

Un socio que necesita un enderezo de orixe fixo para peticións feitas despois de erguer o túnel ten outro requisito: a saída. O que observa un sitio web depende da ruta da aplicación e da política de túnel dividido, non do enderezo ao que se conectou o cliente. O tráfico de túnel dividido pode non tocar AWS en absoluto.

O DNS privado dentro do túnel é unha terceira capa. O resolutor que se entrega aos clientes responde nomes internos tras a conexión; non pode resolver o endpoint público antes de que exista o túnel. O fallo de resolución do endpoint e o fallo de resolución dunha aplicación interna ocorren en fases distintas, e mesturalos lévao ao rexistro equivocado.

A familia de enderezos pertence á mesma lista. Unha resposta IPv4 non di nada sobre a ruta permitida dun endpoint IPv6 ou de dobre pila, así que unha instantánea tomada nunha familia non é evidencia para a outra.

Comprobe unha conexión sen fixar nada

Empece polo perfil tal como se exportou e lea que pide 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)'

Logo compare tres cousas: o nome do endpoint que garda o perfil, o enderezo que o cliente informa para un intento novo e a que resolve o nome agora mesmo. Un nome que resolve só demostra que o rexistro responde; o transporte e a autenticación son aparte, e o endpoint non ten que responder a un ping. O rexistro propio do cliente é a única fonte para o elemento central, así que captúreo durante o intento e non despois.

Un enderezo que responde hoxe é evidencia sobre hoxe; o nome é o que o servizo mantén válido. Anote a observación, envíea a quen posúa o endpoint e deixe o perfil apuntando ao nome.

Dous hábitos que abandonar: desactivar as comprobacións de certificado para pasar un handshake atascado, e apilar etiquetas diante do nome do endpoint esperando que unha pegue. Unha etiqueta resólvese polo rexistro comodín ou o problema está noutro sitio. Se un perfil ben configurado segue fallando, envíe a consulta exacta e o evento de conexión, non un nome de host máis longo.

Antes de pechalo: o perfil segue levando o nome exportado do endpoint, ningún ficheiro hosts fixa o enderezo, o remote do rexistro do cliente coincide cunha resolución actual e a regra de firewall nomea o endpoint en lugar dun enderezo. Ese é tamén o estado que hai que entregar á seguinte persoa.