WireGuard encara fa servir el punt final antic després de canvis al DNS

El túnel va deixar de passar trànsit després que el registre DNS del servidor es mogués, i el nom es resol correctament des del mateix equip. Aquests dos fets no estan en conflicte. Una configuració de WireGuard conté un punt final, i l’eina resol el nom quan aplica aquesta configuració, de manera que la interfície en funcionament pot continuar fent servir l’adreça que va consultar fa hores. Comproveu què fa servir la interfície abans de substituir claus o tocar el rang del túnel.

El nom es resol una vegada, no de manera contínua

La configuració bàsica de WireGuard pren un punt final com a adreça i port, i l’eina que aixeca una interfície resol un nom d’amfitrió en aquell moment. Res del protocol base no consulta el DNS segons un calendari, i una aplicació client pot afegir-hi el seu propi comportament d’actualització. Enregistrar l’adreça resolta, la família i el port al costat del nom fa visible la diferència. Sense aquest registre la configuració sembla correcta mentre la interfície parla amb un altre lloc.

Hi ha una actualització automàtica genuïna, i val la pena conèixer-la perquè s’assembla a una actualització de DNS sense ser-ho. Un punt final de parell es pot moure quan arriba trànsit correctament autenticat des d’una adreça nova, cosa que és itinerància i no resolució de noms. Segueix el parell, així que no pot descobrir un servidor nou no relacionat amb què l’extrem antic mai no hagi contactat.

Compareu el registre amb l’adreça en ús

Consulteu el nom documentat a través del resolutor que fa servir el client i després pregunteu a la interfície quin punt final té. Les dues respostes són la comparació que decideix la resta d’aquesta pàgina:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

El manual wg(8) documenta les subordres show que fan servir aquestes línies. Compareu també la família de l’adreça, no només l’adreça, perquè un registre que ha guanyat una entrada IPv6 és una comparació diferent d’un a qui ha canviat l’adreça IPv4. Si el punt final difereix del registre, la interfície funciona amb informació obsoleta i el nom mai no va ser el problema. Si coincideixen i el túnel encara falla, aneu a l’oient i a les regles, no al perfil.

La marca de temps de l’encaixada de mans és en aquell bloc perquè el punt final sol no diu si el parell és abastable. Una marca obsoleta al costat d’un punt final correcte és un problema de camí, no de resolució, i aquesta distinció canvia què toqueu després.

Reinicieu a través del gestor de la interfície

Un cop confirmat que el punt final és obsolet, actualitzeu-lo a través del mecanisme que posseeix la interfície en lloc d’editar la configuració en directe. Per a una interfície iniciada per wg-quick això és una baixada i una pujada, per a una unitat systemd és un reinici, i per a una interfície propietat d’un gestor és un canvi fet en aquell gestor, perquè una edició en temps d’execució es sobreescriu en la propera aplicació:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Després confirmeu que l’oient de substitució i la seva identitat són el servei que volíeu. Un moviment de DNS no és un canvi d’identitat, així que no hauria de ser mai l’ocasió de confiar en una clau que no heu verificat. Si la interfície ara informa de l’adreça nova i encara no produeix cap encaixada de mans, la fallada s’ha traslladat al camí de xarxa nou o a l’oient, cosa que és progrés i no la mateixa fallada dues vegades.

Primer l’encaixada de mans, després el camí de dades

Separeu els dos resultats abans de triar una llista de verificació. Una encaixada de mans que té èxit sota una aplicació que falla és un problema del camí de dades: rutes, prefixos permesos o DNS dins del túnel. Una encaixada de mans que no passa mai és un problema d’abastabilitat o d’identitat al punt final. Barrejar les dues coses produeix un informe que ningú no pot reproduir i un registre de canvis amb tres edicions no relacionades.

Enregistreu el nom, l’adreça resolta, el punt final en ús i si l’encaixada de mans s’ha completat. Aquests quatre fets responen la pregunta que aquesta fallada no para de fer, i converteixen la propera ocurrència en una comprovació de dos minuts. El manteniment del nom i l’adopció del client continuen sent feines separades: corregir el registre no fa l’adopció, i reiniciar la interfície no arregla un registre que encara és incorrecte.