Per què una reserva DHCP no és una IP fixa per al teu servidor VPN

Vaig traslladar una caixa VPN domèstica del Wi-Fi a l’Ethernet i la seva adreça «permanent» va canviar aquella mateixa tarda. Al router no hi havia res espatllat. La reserva coincidia amb l’adaptador sense fil, i aquell adaptador ja no era al camí.

Hi ha una segona meitat del mateix malentès. Arreglar l’adreça LAN no fa res per l’adreça a què es connecten els teus amics, i no té res a veure amb el pool privat que el VPN lliura als clients. Tres adreces, tres maneres de fallar separades, i només una és feina d’una reserva.

Una reserva coincideix amb un client, no amb un dispositiu

A DHCPv4 la reserva es basa en l’adreça de maquinari del client; a DHCPv6 es basa en un DUID que s’espera que el client conservi. El camp hostname és una etiqueta per a humans. El que el router compara realment és l’identificador que arriba a la sol·licitud.

Llegeix l’entrada com un condicional: quan aquest identificador ho demana, dona-li aquesta adreça. Les renovacions mantenen la mateixa concessió mentre es manté la coincidència, i un reinici només torna a demanar. Quan l’identificador canvia, la sol·licitud falla la reserva i el client pren el que ofereixi el pool dinàmic. Cap error, cap avís, només una adreça diferent.

OpenWrt mostra la forma amb claredat. Un bloc config host a /etc/config/dhcp lliga un nom, una MAC i una adreça, i la documentació de les concessions estàtiques explica com interactua aquesta entrada amb el pool. Altres routers amaguen els mateixos tres camps darrere d’etiquetes diferents.

On la coincidència es trenca en silenci

Canviar maquinari és el cas habitual. Canvia la NIC, o mou la màquina entre Ethernet i Wi-Fi, i l’adreça que veu el router canvia amb ella. La reserva antiga es queda a la llista, encara semblant correcta.

Una reinstal·lació és el segon cas, i mossega més fort a IPv6. Una instal·lació nova pot generar un DUID nou mentre la concessió IPv4 antiga encara és vàlida, així que l’adreça v4 sobreviu un temps i l’entrada v6 deixa d’aplicar-se sense cap edició visible.

El tercer és un identificador de client fixat. Diversos clients DHCP permeten definir una cadena d’identificador en lloc d’usar la MAC. Si una actualització o una reescriptura de la configuració elimina aquest paràmetre, la coincidència desapareix encara que la màquina no s’hagi mogut.

El quart és la duplicació: un bloc antic i un bloc nou per al mateix host. El servidor respon amb la regla que coincideixi, sovint l’adreça del pool que volies evitar. Esborra l’entrada antiga en lloc d’afegir-ne una segona.

Configuració al costat del host i què costa

Posar l’adreça al host elimina del tot la qüestió de la coincidència. La interfície puja amb aquella adreça tant si DHCP respon com si no, que és el que vols d’una màquina que ha de ser accessible després de reiniciar el router.

El cost és la propietat. Ara tu proporciones el prefix, la porta d’enllaç i els resolvers, i has de mantenir l’adreça fora del pool dinàmic tu mateix. A Ubuntu amb netplan, ho porta /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]

Els usuaris de NetworkManager arriben al mateix estat amb nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, i després nmcli con up "Wired connection 1". Aplica netplan amb netplan try al primer intent en lloc de netplan apply; una porta d’enllaç mal escrita treu la màquina de la xarxa i et deixa buscant una consola.

Mantingues igualment una reserva que coincideixi. No és redundant. L’entrada registra l’adreça al costat del router i evita que el servidor DHCP doni aquesta adreça a un dispositiu convidat si algú amplia el pool més endavant.

Una adreça LAN estable no és un punt final públic

Apunta el port forward a 192.168.50.10 i la regla sobreviu a cada canvi al costat LAN. No et dona una adreça d’internet estable. La teva IP pública pertany a l’ISP i es pot moure en una reconnexió o un canvi de mòdem, que és per a què serveix el DNS dinàmic.

Darrere d’un NAT de nivell d’operador no hi ha cap IPv4 pública per redirigir, i cap reserva no la crea. Comprova la pàgina WAN del router abans que res: si l’adreça és en un rang compartit, el port forwarding entrant no pot funcionar per neta que sigui la reserva.

La tercera adreça és el pool del túnel, sovint una cosa com 10.8.0.0/24. Aquestes adreces només existeixen dins del túnel i no apareixen mai a la LAN. Confondre-les amb l’adreça LAN del servidor és com un port acaba redirigit a un client que només és en línia mentre està connectat.

Comprova el camí en l’ordre en què es trenca

Comença al router. Compara l’entrada de la taula de concessions amb l’objectiu de la reserva; si el servidor ha pres una adreça del pool, l’identificador és incorrecte, i ip link show al host et dona el valor per comparar.

Després el host. ip -4 addr show eth0 hauria d’informar de l’adreça i el prefix esperats. Una segona adreça a la mateixa interfície normalment vol dir que DHCP encara corre al costat de la teva configuració estàtica.

Després el forward. Confirma que la destinació encara és igual a l’adreça que acabes de verificar, i confirma que hi ha alguna cosa escoltant amb ss -lntp. Un forward cap a un port tancat sembla exactament un forward trencat des de fora.

Acaba des de fora, en un telèfon amb el Wi-Fi apagat. Aquest únic test separa «l’adreça local és incorrecta» de «l’abast públic està trencat», els dos problemes que aquesta configuració no para de barrejar.

Apunta les tres adreces —LAN, pública i pool del túnel— i anota quin sistema posseeix cadascuna. Quan el mes que ve falli una connexió, sabràs quina inspeccionar en lloc de canviar les tres alhora.