Nom de punt final de VPN versus nom de servei privat: dos propietaris

Dos noms poden descriure la mateixa branca i respondre preguntes completament diferents. vpn.branch.example diu a un igual remot on trobar el punt final de VPN, i s’ha de resoldre abans que existeixi cap túnel. inventory.branch.example diu a un usuari autoritzat on viu una aplicació privada, i només importa un cop el túnel està aixecat. Mantenir un d’ells no fa res per l’altre.

Anomeneu els dos registres abans de depurar qualsevol dels dos

Escriviu-los tots dos amb els seus propietaris. Per al punt final, anoteu qui actualitza l’adreça pública i com el client VPN refresca la seva resposta. Per al servei, anoteu qui posseeix l’adreça privada, quina zona conté el registre i quins resolutors han de respondre’n.

Aquesta llista curta evita el diagnòstic erroni més comú en aquest àmbit: reiniciar un túnel de branca que funciona per reparar un registre que viu del tot a dins seu. El túnel és el transport del nom del servei; no n’és l’autoritat.

Quan es proposa un canvi, pregunteu quin dels dos registres toca. Si ningú no ho pot respondre, el canvi no està llest per programar-se.

El punt final s’ha de resoldre abans que existeixi cap túnel

Suposeu que la connexió a internet de la branca rep una adreça pública nova. L’actualitzador del punt final publica l’adreça nova, i la implementació remota de VPN ha de poder llegir la resposta canviada. El resolutor que doni aquesta resposta ha de ser abastable sense el túnel, o el client persegueix un nom que només pot resoldre després de connectar-se a allò que no pot trobar.

Aquesta dependència d’arrencada val la pena dir-la clarament, perquè és fàcil de crear per accident quan tots els resolutors interns són darrere la VPN. Mantingueu un camí previ al túnel per a la consulta del punt final, i confirmeu el comportament de reconnexió del client en lloc de suposar que una resposta nova es recull immediatament.

El DNS dinàmic també té límits que l’actualització del registre no pot travessar. Actualitzar un registre no obre cap port de tallafocs, no crea cap mapatge NAT i no demostra cap identitat d’igual. Una adreça publicada amb un port tancat dóna un client que resol correctament i tot i així no es pot connectar a res.

Finalment, un client en execució pot continuar usant un punt final en memòria cau fins que es reconnecti. Separeu la publicació, la memòria cau i la política de reconnexió a les vostres notes, perquè un igual obsolet no es confongui amb un actualitzador espatllat.

El nom del servei descriu on viu l’aplicació

Ara suposeu que el túnel es manté sa però el servidor d’inventari es mou de 172.26.14.20 a 172.26.14.35. El registre públic del punt final no queda afectat, mentre que el registre privat del servei ha de canviar. Fer servir una adreça reservada per a aquest servei, o una assignació estàtica, fa que això sigui més rar; un camí d’actualització autoritzat cobreix les vegades en què és volgut.

Aquí es confonen dos mecanismes d’actualització. RFC 2136 defineix un protocol per afegir i suprimir registres DNS en una zona, mentre que un proveïdor comercial de DNS dinàmic pot exposar una API HTTP completament diferent per a una altra finalitat. Usar-ne un no implica que l’altre existeixi al vostre entorn. Comproveu quin mecanisme accepta realment la vostra zona abans d’escriure-hi un actualitzador.

Una resposta privada correcta és només la primera condició. Perquè un cridador remot la pugui usar, el client necessita un resolutor que porti la zona privada, una política que permeti consultes a aquest resolutor i reenviament per a l’adreça que torna. Un nom que resol a una adreça que el client no pot abastar produeix un temps d’espera que sembla una fallada del servidor.

Proveu els dos camins per separat

Comproveu el punt final des de fora del túnel i el servei des de dins, i guardeu els resultats com dos fets independents:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Si la primera consulta falla, el problema és la publicació pública o el camí de resolució previ al túnel, i cap canvi intern hi ajudarà. Si la segona torna una adreça però la tercera no mostra cap ruta pel túnel, la capa DNS està bé i la política de reenviament no.

Executeu la parella després de cada canvi d’adreça i anoteu quin registre s’ha mogut. Un traspàs que només diu «el DNS s’ha actualitzat» deixa el següent enginyer endevinant quin dels dos cicles de vida s’ha executat realment.