Por que unha reserva DHCP non é unha IP fixa para o teu servidor VPN

Trasladei unha caixa VPN doméstica do Wi-Fi ao Ethernet e o seu enderezo «permanente» cambiou esa mesma tarde. No router non había nada roto. A reserva coincidía co adaptador sen fíos, e ese adaptador xa non estaba no camiño.

Hai unha segunda metade do mesmo malentendido. Arranxar o enderezo LAN non fai nada polo enderezo ao que se conectan os teus amigos, e non ten nada que ver co pool privado que a VPN entrega aos clientes. Tres enderezos, tres modos de fallo separados, e só un deles é traballo dunha reserva.

Unha reserva coincide cun cliente, non cun dispositivo

En DHCPv4 a reserva baséase no enderezo de hardware do cliente; en DHCPv6 baséase nun DUID que se espera que o cliente conserve. O campo hostname é unha etiqueta para humanos. O que o router compara de verdade é o identificador que chega na solicitude.

Le a entrada como un condicional: cando este identificador pregunta, dálle este enderezo. As renovacións manteñen a mesma concesión mentres se sostén a coincidencia, e un reinicio só volve preguntar. Cando o identificador cambia, a solicitude falla a reserva e o cliente toma o que ofreza o pool dinámico. Sen erro, sen aviso, só un enderezo distinto.

OpenWrt mostra a forma con claridade. Un bloque config host en /etc/config/dhcp une un nome, unha MAC e un enderezo, e a documentación das concesións estáticas explica como interactúa esa entrada co pool. Outros routers esconden os mesmos tres campos detrás de etiquetas distintas.

Onde a coincidencia se rompe en silencio

Cambiar hardware é o caso habitual. Cambia a NIC, ou move a máquina entre Ethernet e Wi-Fi, e o enderezo que ve o router cambia con ela. A reserva antiga queda na lista, aínda parecendo correcta.

Unha reinstalación é o segundo caso, e morde máis forte en IPv6. Unha instalación nova pode xerar un DUID novo mentres a concesión IPv4 antiga segue vixente, así que o enderezo v4 sobrevive un tempo e a entrada v6 deixa de aplicarse sen ningunha edición visible.

O terceiro é un identificador de cliente fixado. Varios clientes DHCP permiten definir unha cadea de identificador en lugar de usar a MAC. Se unha actualización ou unha reescritura da configuración elimina ese axuste, a coincidencia desaparece aínda que a máquina non se movese.

O cuarto é a duplicación: un bloque antigo e un bloque novo para o mesmo host. O servidor responde coa regra que coincida, a miúdo o enderezo do pool que querías evitar. Borra a entrada antiga en lugar de engadir unha segunda.

Configuración no lado do host e o que custa

Pór o enderezo no host elimina por completo a cuestión da coincidencia. A interface sobe con ese enderezo responda ou non DHCP, que é o que queres dunha máquina que debe ser accesible tras reiniciar o router.

O custo é a propiedade. Agora ti forneces o prefixo, a porta de enlace e os resolvedores, e debes manter o enderezo fóra do pool dinámico ti mesmo. En Ubuntu con netplan, lévao /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]

Os usuarios de NetworkManager chegan ao mesmo estado con nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, e despois nmcli con up "Wired connection 1". Aplica netplan con netplan try no primeiro intento en lugar de netplan apply; unha porta de enlace mal escrita saca a máquina da rede e déixate buscando unha consola.

Mantén igualmente unha reserva que coincida. Non é redundante. A entrada rexistra o enderezo no lado do router e evita que o servidor DHCP dea ese enderezo a un dispositivo convidado se alguén amplía o pool máis adiante.

Un enderezo LAN estable non é un punto final público

Apunta o port forward a 192.168.50.10 e a regra sobrevive a cada cambio no lado LAN. Non che dá un enderezo de internet estable. A túa IP pública pertence ao ISP e pode moverse nunha reconexión ou un cambio de módem, que é para o que serve o DNS dinámico.

Detrás dun NAT de nivel de operador non hai ningún IPv4 público que redirixir, e ningunha reserva crea un. Comproba a páxina WAN do router antes que nada: se o enderezo está nun rango compartido, o reenvío entrante non pode funcionar por limpa que sexa a reserva.

O terceiro enderezo é o pool do túnel, a miúdo algo como 10.8.0.0/24. Eses enderezos só existen dentro do túnel e nunca aparecen na LAN. Confundilos co enderezo LAN do servidor é como un porto acaba redirixido a un cliente que só está en liña mentres está conectado.

Comproba o camiño na orde en que se rompe

Comeza no router. Compara a entrada da táboa de concesións co obxectivo da reserva; se o servidor tomou un enderezo do pool, o identificador está mal, e ip link show no host dache o valor para comparar.

Logo o host. ip -4 addr show eth0 debería informar do enderezo e o prefixo esperados. Un segundo enderezo na mesma interface normalmente significa que DHCP segue correndo xunto á túa configuración estática.

Logo o reenvío. Confirma que o destino segue sendo igual ao enderezo que acabas de verificar, e confirma que algo escoita con ss -lntp. Un reenvío cara a un porto pechado parece exactamente un reenvío roto desde fóra.

Termina desde fóra, nun teléfono co Wi-Fi apagado. Esa única proba separa «o enderezo local está mal» de «a accesibilidade pública está rota», os dous problemas que esta configuración non deixa de mesturar.

Apunta os tres enderezos —LAN, pública e pool do túnel— e anota que sistema posúe cada un. Cando o mes que vén falle unha conexión, saberás cal inspeccionar en lugar de cambiar as tres á vez.