DNS en AWS Client VPN: use o resolver da VPC, non a subrede
O resolver dun endpoint de AWS Client VPN é o rango principal da VPC máis dous, non cada subrede máis dous. Configúreo, encamíneo e despois revise o cliente.
O endpoint está en 10.0.8.0/24, así que o resolver debe ser 10.0.8.2. Ese é o razoamento que máis oio, e é erróneo dúas veces. Route 53 Resolver responde no rango IPv4 principal da VPC máis dous, que para unha VPC de 10.0.0.0/16 é 10.0.0.2, sen importar que subrede use o endpoint. O segundo erro é máis silencioso: poñer o enderezo correcto no endpoint non significa que o sistema operativo do cliente lle pregunte algo algunha vez. Ambos os erros producen o mesmo síntoma: a resolución de nomes funciona nalgúns clientes e falla noutros.
O mito comeza na asociación da subrede
A asociación trata de onde viven as interfaces de rede elásticas para as conexións de clientes, non de que enderezo de resolver existe. As subredes do endpoint dan aos clientes un enderezo dentro da VPC, e ningunha leva o seu propio resolver.
Cando separa esas dúas ideas, a aritmética deixa de ser misteriosa e a resolución de problemas pasa ao cliente, que é onde acaban realmente a maioría destes casos.
Calcule o enderezo desde o rango principal da VPC
Tome o CIDR IPv4 principal da VPC e sume dous ao enderezo de rede. 10.0.0.0/16 dá 10.0.0.2, 172.31.0.0/16 dá 172.31.0.2, e unha VPC cun rango secundario mantén o resolver no principal. Unha subrede de 10.0.8.0/24 dentro desa VPC non o move. Anote o enderezo xunto ao ID da VPC antes de tocar o endpoint, porque o número é unha propiedade da VPC e non da conexión.
A VPC tamén responde no enderezo link-local 169.254.169.253. Ese enderezo é accesible desde dentro da VPC, pero non é un destino encamiñado de uso xeral para un portátil na outra punta dun túnel.
Así que hai dous enderezos de resolver válidos, e ningún deles é a subrede máis dous.
Que fai e que non fai o axuste do endpoint
O endpoint de Client VPN ten campos de servidor DNS, e onde a consola ofrece unha opción de resolver da VPC enche a mesma idea. Configuralos cambia o que o servizo entrega aos clientes durante o establecemento da conexión. Non cambia o que fai un cliente OpenVPN non xestionado con ese valor, porque o cliente aínda debe aplicalo ao sistema operativo. Desta fenda vén «funciona no meu Mac pero non na máquina Linux».
En Linux, a integración do resolver é propiedade do xestor de conexións e non do usuario. Editar /etc/resolv.conf a man demostra que o enderezo funciona para unha sesión e despois desaparece ao reconectar, por iso tantos casos arranxados volven á mañá seguinte.
Revise o resolver activo no cliente despois de conectar, non a páxina de configuración do endpoint.
O tunneling dividido pode anular un resolver correcto
Co tunneling dividido só se usan as rutas enviadas ao túnel. Se o enderezo do resolver non está cuberto por unha ruta, a consulta sae pola interface local e respóndea o seu router doméstico. O enderezo do endpoint segue sendo correcto e a busca segue fallando. Engada a ruta para o resolver e probe de novo.
Os rangos locais solapados producen o mesmo resultado dun xeito máis desagradable: a consulta recibe resposta, pero do servidor equivocado.
Non abra grupos de seguridade para o enderezo de Amazon DNS
O instinto cando as consultas esgotan o tempo é engadir unha regra que permita UDP 53 cara ao enderezo do resolver. AWS documenta que os grupos de seguridade e as ACL de rede non filtran o tráfico de Amazon DNS como filtran o tráfico cara a unha instancia DNS propia. Abrir esas regras non cambia nada para o resolver da VPC e amplía o perímetro sen motivo. Un resolver que vostede mesmo opera é outro caso e si precisa as súas propias regras.
Se ambos aparecen no seu deseño, comprobe a cal apunta realmente o cliente antes de editar calquera regra.
Verifique a ruta e logo mida outra cousa
Resolva un nome público, resolva un nome privado rexistrado nunha zona aloxada privada asociada á VPC e lea o resolver activo do cliente entre ambos. Esa secuencia separa «o enderezo do resolver é incorrecto» de «a zona non está asociada» e de «o cliente ignorou o axuste». Cada un ten unha solución distinta e ningún é un problema de rendemento.
Unha busca correcta non di nada sobre a velocidade sostida de transferencia, así que manteña esas dúas conversacións separadas ao informar.