DNS de l'extrem d'AWS Client VPN: per què falla fixar la IP resolta
Substitueix el nom de l'extrem d'AWS Client VPN per l'adreça que vas resoldre i el túnel deixarà de funcionar més tard. Conserva el nom exportat i el seu prefix aleatori.
La setmana passada dig +short et va donar una adreça per al nom de l'extrem del teu perfil d'AWS Client VPN, i el túnel es va connectar. Aquesta setmana el mateix perfil es queda a 'Connecting' al teu portàtil mentre la còpia intacta d'un company encara funciona. No s'ha bloquejat res i el certificat no ha caducat. Algú va substituir el nom d'amfitrió de l'extrem per aquella adreça resolta, i el servei ja no respon allà. El nom exportat és la part dissenyada per sobreviure a aquest canvi.
El nom del teu perfil pot no ser el nom que es consulta
Els perfils exportats de Client VPN sovint porten remote-random-hostname. Amb aquesta opció activada, el client crea una etiqueta d'un sol ús, la uneix al nom de l'extrem amb un punt i resol el nom combinat. Un registre comodí a la zona de l'extrem respon a qualsevol etiqueta, per això un prefix inventat també es resol i per això el truc passa desapercebut quan intentes reproduir la consulta a mà.
Així, quan enganxes el nom de l'extrem en un terminal i obtens una resposta, has resolt un nom diferent del que el client fa servir en connectar-se. Aquesta discrepància no és un defecte que calgui corregir al perfil. L'etiqueta es regenera expressament: l'opció evita que les memòries cau retinguin una resposta obsoleta i mai identifica la teva màquina ni la teva sessió.
M'he trobat amb el cas de compatibilitat en què un client ignora l'opció directament. AWS documenta la solució: conserva el nom real de l'extrem i afegeix-hi davant una cadena aleatòria més un punt, tractant-ho com un patró de nomenclatura i no com un valor per enganxar. Aplicar-ho a un client antic és raonable; codificar la cadena amb prefix com a extrem no ho és.
Per què una resposta desada no pot mantenir-se correcta
Les adreces de l'extrem de Client VPN les gestiona AWS i canvien amb el temps, cosa que la documentació de bones pràctiques diu clarament. Una resposta capturada és una instantània d'una resolució. Un perfil que la codifica es converteix en un perfil adreçat a un amfitrió fora de servei tan bon punt el servei es mou, i la fallada poques vegades sembla DNS: obtens un temps d'espera de connexió o un handshake encallat, i la gent persegueix encaminament i certificats.
La mateixa resposta a /etc/hosts hereta la mateixa caducitat amb un problema extra. Una entrada hosts sobreviu a reinicis, reexportacions i arranjaments de 'reinstal·la el client', així que la fallada torna cada cop que l'adreça es mou. N'he vist una que va estar setmanes sense fer mal, i després va deixar fora de joc totes les màquines que la portaven mentre les instal·lacions noves es connectaven amb normalitat. Aquesta divisió, un grup que falla i un altre que va bé al mateix compte, és la pista més barata que tindràs.
Delimita bé l'abast de l'aleatorització. Passa a cada intent de connexió. Un túnel establert no torna a resoldre el seu extrem, no canvia de servidor a mig camí i les peticions individuals de les aplicacions no trien cadascuna un amfitrió VPN nou. Només el següent intent torna a resoldre, per això una sessió que funciona tota la tarda no diu res sobre el matí de demà.
Què comprova el servei quan el túnel s'aixeca
Client VPN exigeix que l'adreça a la qual estàs connectat coincideixi amb una adreça resolta per al nom DNS de l'extrem. Aquest sol requisit explica diverses fallades que semblen no relacionades: un registre DNS personalitzat que apunta enlloc més, un frontend personalitzat que reenvia a l'adreça real de l'extrem i un perfil reescrit a una adreça crua. AWS documenta la combinació de registre personalitzat més reenviament com una fallada amb clients recents d'AWS. La comprovació és estreta; no és una sentència que tot àlies estigui prohibit.
Tampoc no és una regla general sobre protocols VPN. Un remote numèric és perfectament vàlid en un desplegament OpenVPN corrent, i molts funcionen així. La restricció ve de la disposició gestionada, no del protocol que hi ha a sota.
Això fa que relaxar la verificació del certificat sigui el reflex equivocat. Si un perfil falla després d'un canvi d'adreça, desactivar la verificació del servidor mou l'error en lloc d'arreglar la resolució o el requisit de coincidència d'adreça, i deixa un client que es fiarà de qualsevol cosa. Mantén el CA exportat, la verificació del servidor i la configuració d'autenticació mútua exactament com van arribar.
Llistes d'autorització, sortida i DNS privat són tres problemes separats
Una regla de firewall que ha de permetre una destinació abans que un portàtil es connecti tracta del receptor exterior. Dona al propietari de la xarxa el nom de l'extrem, el transport i el port configurat, i després pregunta si el seu control pot seguir el comportament DNS del servei. Una regla que reté una adreça capturada és una instantània amb una caducitat no escrita. Si el control només accepta destinacions immutables, resol aquest buit abans del desplegament en lloc de codificar una resposta en silenci.
Un soci que necessita una adreça d'origen fixa per a peticions fetes després que el túnel estigui aixecat té un requisit diferent: la sortida. El que observa un lloc web depèn de la ruta de l'aplicació i de la política de túnel dividit, no de l'adreça a la qual es va connectar el client. El trànsit per túnel dividit pot no tocar mai AWS.
El DNS privat dins del túnel és una tercera capa. El resolutor que es lliura als clients respon noms interns després de la connexió; no pot resoldre l'extrem públic abans que existeixi el túnel. La fallada de resolució de l'extrem i la d'una aplicació interna passen en etapes diferents, i barrejar-les et porta al registre equivocat.
La família d'adreces pertany a la mateixa llista. Una resposta IPv4 no diu res sobre el camí permès d'un extrem IPv6 o de doble pila, així que una instantània presa en una família no és evidència per a l'altra.
Comprova una connexió sense fixar res
Comença pel perfil tal com es va exportar i llegeix què demana realment:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'Després compara tres coses: el nom de l'extrem que té el perfil, l'adreça que el client informa per a un intent nou i a què es resol el nom ara mateix. Un nom que es resol només demostra que el registre respon; el transport i l'autenticació són a part, i l'extrem no ha de respondre a un ping. El registre propi del client és l'única font per a l'element central, així que captura'l durant l'intent i no després.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
Una adreça que respon avui és evidència sobre avui; el nom és el que el servei manté vàlid. Anota l'observació, envia-la a qui posseeixi l'extrem i deixa el perfil apuntant al nom.
Dos hàbits a deixar: desactivar les comprovacions de certificat per passar un handshake encallat, i apilar etiquetes davant del nom de l'extrem esperant que una enganxi. Una etiqueta es resol pel registre comodí o el problema és en un altre lloc. Si un perfil ben configurat encara falla, envia la consulta exacta i l'esdeveniment de connexió, no un nom d'amfitrió més llarg.
Abans de tancar-ho: el perfil encara porta el nom exportat de l'extrem, cap fitxer hosts fixa l'adreça, el remote del registre del client coincideix amb una resolució actual i la regla de firewall anomena l'extrem, no una adreça. Aquest és també l'estat que cal lliurar a la propera persona.