Necessites DNS dinàmic per a un servidor VPN domèstic?

La majoria de fallades de VPN domèstica que em pregunten no són fallades de DNS, i tot i així compren primer una subscripció de DNS dinàmic. Abans de configurar res, decidiu si el nom d’amfitrió és la part que realment està trencada. Un actualitzador reescriu un registre quan l’adreça que us ha donat el proveïdor es mou; no pot obrir un port, travessar el NAT de l’operador ni fer que una sessió de WireGuard activa noti que el seu punt final ha canviat. Tres condicions decideixen si el DNS dinàmic és tota la solució o només una línia.

Primera condició: la teva adreça es mou de debò

Les adreces residencials es mouen per motius banals: el mòdem resincronitza després d’un tall de llum, el proveïdor reequilibra un pool, un nou lloguer arriba després d’una avaria llarga. També es mouen poques vegades en algunes línies, i he vist la mateixa adreça durar un any; els plans d’empresa sovint inclouen una de fixa. Si res no ha canviat en dotze mesos, un sol registre A que editeu a mà és un dimoni menys per mantenir viu.

Mesureu-ho en lloc d’endevinar. Llegiu l’adreça WAN a la pàgina d’estat del router i compareu-la amb el que veu el món exterior. Executeu això des d’una màquina de la LAN:

curl -fsS https://api.ipify.org; echo

Si els dos valors difereixen, hi ha alguna cosa traduint davant del router i cap actualització de nom d’amfitrió ho arreglarà. Una adreça dins de 100.64.0.0/10 és el rang compartit per al NAT de nivell d’operador, i és el motiu habitual que un nom actualitzat correctament encara expiri des de fora.

Segona condició: els clients tornen a consultar el nom

El TTL curt és la part que la gent s’estalvia. Els resolvers recursius respecten el TTL del registre, però les piles de client fan memòria cau per separat, i un túnel ja enlairat no torna a resoldre res. Posa el registre a 60-300 segons mentre depures; això escurça la finestra en què se serveix una resposta antiga i no migra una sessió connectada.

OpenVPN torna a resoldre la línia remote vpn.example.net 1194 cada cop que es reconnecta, i resolv-retry infinite el fa reintentar en lloc de sortir quan la consulta falla. Al servidor, float permet que una sessió establerta segueixi un parell l’adreça d’origen del qual ha canviat. WireGuard és més directe: wg-quick up resol el Endpoint quan s’aplica la configuració, i el client el torna a resoldre quan reconstrueix el túnel, així que un handshake que encara funciona contra l’adreça antiga continua funcionant fins que s’atura.

Aquesta diferència dona forma al pla. Si els clients es connecten a demanda, un canvi d’adreça costa una reconnexió. Si mantenen una sessió oberta durant dies, espereu que el túnel mori al següent handshake, i feu que el client reintenti en lloc de suposar que aguanta.

Tercera condició: el camí d’entrada encara és obert

El DNS dinàmic canvia on apunta el nom i res més. El desviament de port al router, la regla de tallafoc a l’amfitrió VPN i el permís de l’ISP per als paquets entrants han d’existir abans que el registre importi. Fixeu-vos on apunta el desviament: si està fixat a una adreça WAN en lloc de la interfície, un canvi d’adreça trenca el desviament en silenci i el registre s’endú la culpa.

Prova-ho des de fora. Un mòbil amb dades mòbils i el Wi-Fi apagat és la prova honesta més barata; un portàtil a la mateixa LAN no ho és. Quan el nom resol a la teva adreça pública i el router no té bucle NAT, una prova interior falla mentre el registre és del tot correcte, i això envia la majoria de gent a editar un registre que mai no havia estat malament.

Què executar quan les tres es compleixen

ddclient és l’actualitzador que menys sorprèn per a un amfitrió petit. Una configuració mínima publica l’adreça que veu el proveïdor, cosa que evita l’error del doble NAT:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Executeu-lo des d’un temporitzador de systemd cada pocs minuts en lloc d’un bucle de shell, i registreu la resposta del proveïdor en lloc de suposar èxit. Tracteu la credencial com una clau, perquè decideix on s’envia cada client: useu un testimoni d’actualització limitat en lloc d’una contrasenya de compte, manteniu el fitxer en mode 0600 i envieu les actualitzacions per HTTPS.

Verifica abans de comprometre’t

Una consulta et diu què veu la resta del món i imprimeix el TTL que has d’esperar després d’un canvi:

dig +noall +answer vpn.example.net @1.1.1.1

Compareu aquesta adreça amb l’adreça WAN del router. Si coincideixen, el nom fa la seva feina i el que encara falla és accessibilitat entrant, una clau o un client que no ha tornat a resoldre. Si difereixen, l’actualitzador publica la interfície equivocada, sovint perquè s’executava a l’amfitrió VPN darrere del router en lloc del router mateix.

Manteniu una reversió que trigui un minut: anoteu l’última adreça que funcionava i el TTL anterior, perquè pugueu publicar les dues a mà mentre el proveïdor té una tarda dolenta.

Quan la resposta és no

Si falla la primera o la tercera condició, canvia la decisió i no la configuració. Darrere del NAT de l’operador, les opcions pràctiques són demanar a l’ISP una adreça pública, moure el punt d’entrada a un VPS petit amb una adreça estable, o fer servir una capa superposada que mantingui el seu propi encontre. Si l’adreça és fixa, estalvieu-vos l’actualitzador: un registre A, un registre AAAA si feu servir IPv6, el mateix desviament de port.

Si l’adreça canvia mentre els clients segueixen connectats, la solució honesta viu al client: lògica de reconnexió i un interval de reintent, no un actualitzador més ràpid. Afegir un segon proveïdor només amaga l’interval.

Abans de continuar, confirmeu quatre coses en ordre:

• L’adreça que publica l’actualitzador coincideix amb l’adreça WAN del router.
• El TTL del registre és prou curt perquè un canvi aparegui en minuts.
• El desviament de port està lligat a la interfície, no a una adreça fixa.
• Un client real s’ha reconnectat i ha passat trànsit des de l’últim canvi.

Si les quatre es compleixen, deixeu la configuració tranquil·la; la propera fallada és una clau o una regla de tallafoc, no un problema de noms. Si alguna falla, arregleu aquella fila abans d’afegir una altra peça mòbil. RFC 2136 descriu el mecanisme d’actualització, si voleu veure què posa el dimoni al fil.