Precisas DNS dinámico para un servidor VPN doméstico?

A maioría das fallas de VPN doméstica que me consultan non son fallas de DNS, e aínda así compran primeiro unha subscrición de DNS dinámico. Antes de configurar nada, decide se o nome de host é a parte que está realmente rota. Un actualizador reescribe un rexistro cando o enderezo que che deu o teu ISP se move; non pode abrir un porto, atravesar o NAT do operador nin facer que unha sesión de WireGuard activa note que o seu extremo cambiou. Tres condicións deciden se o DNS dinámico é toda a solución ou só unha liña dela.

Condición un: o teu enderezo móvese de verdade

Os enderezos residenciais móvense por motivos anodinos: o módem resincroniza tras un corte de luz, o ISP reequilibra un grupo, un novo arrendamento chega tras unha avaría longa. Tamén se moven pouco nalgunhas liñas, e vin o mesmo enderezo sobrevivir un ano; os plans de empresa adoitan incluír unha fixa. Se nada cambiou en doce meses, un só rexistro A que editas a man é un demo menos que manter vivo.

Mídeo en vez de supoñelo. Le o enderezo WAN na páxina de estado do router e compárao co que ve o mundo exterior. Executa isto desde unha máquina da LAN:

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

Se os dous valores difiren, algo está traducindo diante do teu router e ningunha actualización de nome o arranxará. Un enderezo dentro de 100.64.0.0/10 é o rango compartido para NAT de nivel de operador, e esa é a razón habitual de que un nome actualizado correctamente siga esgotando o tempo desde fóra.

Condición dous: os clientes volven resolver o nome

O TTL curto é a parte que a xente salta. Os resolvedores recursivos respectan o TTL do rexistro, pero as pilas de cliente cachean por separado, e un túnel xa levantado non volve resolver nada. Pon o rexistro en 60-300 segundos mentres depuras; iso acurta a fiestra na que se serve unha resposta antiga e non migra unha sesión conectada.

OpenVPN volve resolver a liña remote vpn.example.net 1194 cada vez que se reconecta, e resolv-retry infinite manteno reintentando en vez de saír cando falla a consulta. No servidor, float permite que unha sesión establecida siga un par cuxo enderezo de orixe cambiou. WireGuard é máis directo: wg-quick up resolve o Endpoint ao aplicar a configuración, e o cliente volve resolvelo cando reconstrúe o túnel, así que un handshake que aínda funciona contra o enderezo antigo segue funcionando ata que se detén.

Esa diferenza marca o plan. Se os clientes conectan a demanda, un cambio de enderezo custa unha reconexión. Se manteñen unha sesión aberta durante días, espera que o túnel morra no seguinte handshake, e fai que o cliente reintente en vez de supoñer que se mantén.

Condición tres: o camiño de entrada segue aberto

O DNS dinámico cambia só cara a onde apunta o nome e nada máis. O desvío de porto no router, a regra de cortafocos no host VPN e o permiso do ISP para os paquetes entrantes deben existir antes de que o rexistro importe. Fíxate en que apunta o desvío: se está ancorado a un enderezo WAN en vez de á interface, un cambio de enderezo rompe o desvío en silencio e o rexistro leva a culpa.

Proba desde fóra. Un teléfono con datos móbiles e o Wi-Fi apagado é a proba honesta máis barata; un portátil na mesma LAN non o é. Cando o nome resolve ao teu enderezo público e o router non ten bucle NAT, unha proba interior falla mentres o rexistro é totalmente correcto, e iso manda a maioría a editar un rexistro que nunca estivo mal.

Que executar cando se cumpren as tres

ddclient é o actualizador que menos sorprende para un host pequeno. Unha configuración mínima publica o enderezo que ve o provedor, o que evita o erro do dobre 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

Execútao desde un temporizador de systemd cada poucos minutos en lugar dun bucle de shell, e rexistra a resposta do provedor en vez de supoñer éxito. Trata a credencial como unha clave, porque decide cara a onde se envía cada cliente: usa un token de actualización limitado en lugar dun contrasinal de conta, mantén o ficheiro en modo 0600 e envía as actualizacións por HTTPS.

Verifica antes de comprometerte

Unha consulta diche o que ve o resto do mundo e imprime o TTL que tes que agardar tras un cambio:

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

Compara ese enderezo co enderezo WAN do router. Se coinciden, o nome fai o seu traballo e o que aínda falla é accesibilidade entrante, unha clave ou un cliente que non volveu resolver. Se difiren, o actualizador publica a interface equivocada, a miúdo porque se executaba no host VPN detrás do router en lugar de no router mesmo.

Mantén unha volta atrás dun minuto: anota o último enderezo que funcionou e o TTL anterior, para poder publicar ambos a man mentres o provedor ten unha tarde mala.

Cando a resposta é non

Se falla a condición un ou a tres, cambia a decisión e non a configuración. Detrás do NAT do operador, as túas opcións prácticas son pedir un enderezo público ao ISP, mover o punto de entrada a un VPS pequeno con enderezo estable, ou usar unha capa superposta que manteña o seu propio encontro. Se o enderezo é fixo, salta o actualizador: un rexistro A, un rexistro AAAA se usas IPv6, o mesmo desvío de porto.

Se o enderezo cambia mentres os clientes seguen conectados, o arranxo honesto vive no cliente: lóxica de reconexión e intervalo de reintento, non un actualizador máis rápido. Engadir un segundo provedor só agocha o intervalo.

Antes de seguir, confirma catro cousas en orde:

• O enderezo que publica o actualizador coincide co enderezo WAN do router.
• O TTL do rexistro é o bastante curto para que un cambio apareza en minutos.
• O desvío de porto está atado á interface, non a un enderezo fixo.
• Un cliente real reconectouse e pasou tráfico desde o último cambio.

Se as catro se cumpren, deixa a configuración tranquila; a túa seguinte falla é unha clave ou unha regra de cortafocos e non un problema de nomes. Se algunha falla, arranxa esa fila antes de engadir outra peza móbil. RFC 2136 describe o mecanismo de actualización en si, se queres ver que pon o demo no cable.