DNS d’AWS Client VPN: feu servir el resolutor de la VPC, no la subxarxa

L’endpoint és a 10.0.8.0/24, així que el resolutor ha de ser 10.0.8.2. Aquest és el raonament que sento més sovint, i és erroni dues vegades. Route 53 Resolver respon al rang IPv4 principal de la VPC més dos, que per a una VPC de 10.0.0.0/16 és 10.0.0.2, sigui quina sigui la subxarxa que faci servir l’endpoint. El segon error és més silenciós: posar l’adreça correcta a l’endpoint no vol dir que el sistema operatiu del client li pregunti mai res. Tots dos errors produeixen el mateix símptoma: la resolució de noms funciona per a alguns clients i falla per a altres.

El mite comença amb l’associació de la subxarxa

L’associació tracta d’on viuen les interfícies de xarxa elàstiques per a les connexions dels clients, no de quina adreça de resolutor existeix. Les subxarxes de l’endpoint donen als clients una adreça dins de la VPC, i no cadascuna té un resolutor propi.

Quan separeu aquestes dues idees, l’aritmètica deixa de ser misteriosa i la diagnosi passa al client, que és on acaben realment la majoria d’aquests casos.

Calculeu l’adreça a partir del rang principal de la VPC

Agafeu el CIDR IPv4 principal de la VPC i sumeu dos a l’adreça de xarxa. 10.0.0.0/16 dona 10.0.0.2, 172.31.0.0/16 dona 172.31.0.2, i una VPC amb un rang secundari manté el resolutor al principal. Una subxarxa de 10.0.8.0/24 dins d’aquesta VPC no el mou. Escriviu l’adreça al costat de l’ID de la VPC abans de tocar l’endpoint, perquè el número és una propietat de la VPC i no de la connexió.

La VPC també respon a l’adreça link-local 169.254.169.253. Aquesta adreça és abastable des de dins de la VPC, però no és una destinació encaminada d’ús general per a un portàtil a l’altre extrem d’un túnel.

Per tant, hi ha dues adreces de resolutor vàlides, i cap d’elles no és la subxarxa més dos.

Què fa i què no fa la configuració de l’endpoint

L’endpoint de Client VPN té camps de servidor DNS, i on la consola ofereix una opció de resolutor de la VPC, omple la mateixa idea. Configurar-los canvia el que el servei lliura als clients durant l’establiment de la connexió. No canvia el que fa un client OpenVPN no gestionat amb aquest valor, perquè el client encara l’ha d’aplicar al sistema operatiu. D’aquest buit ve «funciona al meu Mac però no a la màquina Linux».

A Linux, la integració del resolutor és propietat del gestor de connexions i no de l’usuari. Editar /etc/resolv.conf a mà demostra que l’adreça funciona per a una sessió i després desapareix en reconnectar, i per això tants casos arreglats tornen l’endemà al matí.

Comproveu el resolutor actiu al client després de connectar, no la pàgina de configuració de l’endpoint.

El tunneling dividit pot derrotar un resolutor correcte

Amb tunneling dividit només s’utilitzen les rutes enviades al túnel. Si l’adreça del resolutor no queda coberta per cap ruta, la consulta surt per la interfície local i la respon el router de casa. L’adreça de l’endpoint continua sent correcta i la consulta continua fallant. Afegiu la ruta per al resolutor i torneu a provar.

Els rangs locals solapats produeixen el mateix resultat d’una manera més desagradable: la consulta rep resposta, però del servidor equivocat.

No obriu grups de seguretat per a l’adreça d’Amazon DNS

L’instint quan les consultes caduquen és afegir una regla que permeti UDP 53 cap a l’adreça del resolutor. AWS documenta que els grups de seguretat i les ACL de xarxa no filtren el trànsit d’Amazon DNS com filtren el trànsit cap a una instància DNS pròpia. Obrir aquestes regles no canvia res per al resolutor de la VPC i amplia el perímetre sense motiu. Un resolutor que manteniu vosaltres és un cas diferent i sí que necessita les seves pròpies regles.

Si tots dos apareixen al vostre disseny, comproveu a quin apunta realment el client abans d’editar qualsevol regla.

Verifiqueu el camí i després mesureu una altra cosa

Resoleu un nom públic, resoleu un nom privat registrat en una zona allotjada privada associada a la VPC i llegiu el resolutor actiu del client entre els dos. Aquesta seqüència separa «l’adreça del resolutor és incorrecta» de «la zona no està associada» i de «el client ha ignorat la configuració». Cadascun té una solució diferent i cap és un problema de rendiment.

Una consulta correcta no diu res sobre la velocitat sostinguda de transferència, així que manteniu aquestes dues converses separades quan informeu.