Por qué una reserva DHCP no es una IP fija para tu servidor VPN

Trasladé una caja VPN doméstica del Wi-Fi al Ethernet y su dirección «permanente» cambió esa misma tarde. En el router no había nada roto. La reserva coincidía con el adaptador inalámbrico, y ese adaptador ya no estaba en el camino.

Hay una segunda mitad del mismo malentendido. Arreglar la dirección LAN no hace nada por la dirección a la que se conectan tus amigos, y no tiene nada que ver con el grupo privado que la VPN entrega a los clientes. Tres direcciones, tres modos de fallo separados, y solo uno de ellos es trabajo de una reserva.

Una reserva coincide con un cliente, no con un dispositivo

En DHCPv4 la reserva se basa en la dirección de hardware del cliente; en DHCPv6 se basa en un DUID que se espera que el cliente conserve. El campo hostname es una etiqueta para humanos. Lo que el router compara de verdad es el identificador que llega en la solicitud.

Lee la entrada como un condicional: cuando este identificador pregunta, dale esta dirección. Las renovaciones mantienen la misma concesión mientras se sostiene la coincidencia, y un reinicio solo vuelve a preguntar. Cuando el identificador cambia, la solicitud falla la reserva y el cliente toma lo que ofrezca el grupo dinámico. Sin error, sin aviso, solo una dirección distinta.

OpenWrt muestra la forma con claridad. Un bloque config host en /etc/config/dhcp une un nombre, una MAC y una dirección, y la documentación de las concesiones estáticas explica cómo interactúa esa entrada con el grupo. Otros routers esconden los mismos tres campos detrás de etiquetas distintas.

Donde la coincidencia se rompe en silencio

Cambiar hardware es el caso habitual. Cambia la NIC, o mueve la máquina entre Ethernet y Wi-Fi, y la dirección que ve el router cambia con ella. La reserva antigua se queda en la lista, todavía pareciendo correcta.

Una reinstalación es el segundo caso, y muerde más fuerte en IPv6. Una instalación nueva puede generar un DUID nuevo mientras la concesión IPv4 antigua sigue vigente, así que la dirección v4 sobrevive un tiempo y la entrada v6 deja de aplicarse sin ninguna edición visible.

El tercero es un identificador de cliente fijado. Varios clientes DHCP permiten definir una cadena de identificador en lugar de usar la MAC. Si una actualización o una reescritura de la configuración elimina ese ajuste, la coincidencia desaparece aunque la máquina no se haya movido.

El cuarto es la duplicación: un bloque antiguo y un bloque nuevo para el mismo host. El servidor responde con la regla que coincida, a menudo la dirección del grupo que querías evitar. Borra la entrada antigua en lugar de añadir una segunda.

Configuración en el lado del host y qué cuesta

Poner la dirección en el host elimina del todo la cuestión de la coincidencia. La interfaz sube con esa dirección responda o no DHCP, que es lo que quieres de una máquina que debe ser accesible tras reiniciar el router.

El coste es la propiedad. Ahora tú aportas el prefijo, la puerta de enlace y los resolutores, y debes mantener la dirección fuera del grupo dinámico tú mismo. En Ubuntu con netplan, la lleva /etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Los usuarios de NetworkManager llegan al mismo estado con nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, y luego nmcli con up "Wired connection 1". Aplica netplan con netplan try en el primer intento en lugar de netplan apply; una puerta de enlace mal escrita saca la máquina de la red y te deja buscando una consola.

Mantén igualmente una reserva que coincida. No es redundante. La entrada registra la dirección en el lado del router y evita que el servidor DHCP dé esa dirección a un dispositivo invitado si alguien amplía el grupo más adelante.

Una dirección LAN estable no es un punto final público

Apunta el port forward a 192.168.50.10 y la regla sobrevive a cada cambio en el lado LAN. No te da una dirección de internet estable. Tu IP pública pertenece al ISP y puede moverse en una reconexión o un cambio de módem, que es para lo que sirve el DNS dinámico.

Detrás de un NAT de nivel de operador no hay ninguna IPv4 pública que redirigir, y ninguna reserva crea una. Comprueba la página WAN del router antes que nada: si la dirección está en un rango compartido, el reenvío entrante no puede funcionar por limpia que sea la reserva.

La tercera dirección es el grupo del túnel, a menudo algo como 10.8.0.0/24. Esas direcciones solo existen dentro del túnel y nunca aparecen en la LAN. Confundirlas con la dirección LAN del servidor es como un puerto acaba redirigido a un cliente que solo está en línea mientras está conectado.

Comprueba el camino en el orden en que se rompe

Empieza en el router. Compara la entrada de la tabla de concesiones con el objetivo de la reserva; si el servidor tomó una dirección del grupo, el identificador está mal, y ip link show en el host te da el valor para comparar.

Luego el host. ip -4 addr show eth0 debería informar de la dirección y el prefijo esperados. Una segunda dirección en la misma interfaz suele significar que DHCP sigue corriendo junto a tu configuración estática.

Luego el reenvío. Confirma que el destino sigue siendo igual a la dirección que acabas de verificar, y confirma que algo escucha con ss -lntp. Un reenvío hacia un puerto cerrado parece exactamente un reenvío roto desde fuera.

Termina desde fuera, en un teléfono con el Wi-Fi apagado. Esa única prueba separa «la dirección local está mal» de «la accesibilidad pública está rota», los dos problemas que esta configuración no deja de mezclar.

Apunta las tres direcciones —LAN, pública y grupo del túnel— y anota qué sistema posee cada una. Cuando el mes que viene falle una conexión, sabrás cuál inspeccionar en lugar de cambiar las tres a la vez.