Perché una prenotazione DHCP non è un IP statico per il tuo server VPN

Ho spostato un box VPN domestico dal Wi-Fi all’Ethernet e il suo indirizzo «permanente» è cambiato la sera stessa. Sul router non c’era nulla di rotto. La prenotazione corrispondeva all’adattatore wireless, e quell’adattatore non era più sul percorso.

Lo stesso equivoco ha una seconda metà. Sistemare l’indirizzo LAN non fa nulla per l’indirizzo a cui si collegano i tuoi amici, e non ha niente a che vedere con il pool privato che la VPN assegna ai client. Tre indirizzi, tre modalità di guasto separate, e solo una di esse è compito di una prenotazione.

Una prenotazione corrisponde a un client, non a un dispositivo

In DHCPv4 la prenotazione è legata all’indirizzo hardware del client; in DHCPv6 è legata a un DUID che il client dovrebbe mantenere. Il campo hostname è un’etichetta per gli umani. Ciò che il router confronta davvero è l’identificatore che arriva nella richiesta.

Leggi la voce come una condizione: quando questo identificatore chiede, dagli questo indirizzo. I rinnovi mantengono lo stesso lease finché la corrispondenza regge, e un riavvio chiede semplicemente di nuovo. Quando l’identificatore cambia, la richiesta manca la prenotazione e il client prende ciò che offre il pool dinamico. Nessun errore, nessun avviso, solo un indirizzo diverso.

OpenWrt mostra la forma chiaramente. Un blocco config host in /etc/config/dhcp lega un nome, un MAC e un indirizzo, e la documentazione dei lease statici spiega come quella voce interagisce con il pool. Altri router nascondono gli stessi tre campi dietro etichette diverse.

Dove la corrispondenza cade in silenzio

Cambiare hardware è il caso comune. Cambia la NIC, o sposta la macchina tra Ethernet e Wi-Fi, e l’indirizzo che il router vede cambia con essa. La vecchia prenotazione resta nell’elenco, e sembra ancora corretta.

Una reinstallazione è il secondo caso, e morde più forte su IPv6. Un’installazione nuova può generare un DUID nuovo mentre il vecchio lease IPv4 è ancora valido, quindi l’indirizzo v4 sopravvive per un po’ e la voce v6 smette di applicarsi senza alcuna modifica visibile.

Il terzo è un identificatore di client fissato. Diversi client DHCP permettono di impostare una stringa di identificatore invece di usare il MAC. Se un aggiornamento o una riscrittura della configurazione elimina quell’impostazione, la corrispondenza sparisce anche se la macchina non si è mossa.

Il quarto è la duplicazione: un blocco vecchio e un blocco nuovo per lo stesso host. Il server risponde con la regola che corrisponde, spesso l’indirizzo del pool che volevi evitare. Elimina la voce vecchia invece di aggiungerne una seconda.

Configurazione lato host e quanto costa

Impostare l’indirizzo sull’host elimina del tutto la questione della corrispondenza. L’interfaccia sale con quell’indirizzo che DHCP risponda o no, ed è quello che vuoi da una macchina che deve essere raggiungibile dopo un riavvio del router.

Il costo è la proprietà. Ora il prefisso, il gateway e i resolver li fornisci tu, e devi tenere l’indirizzo fuori dal pool dinamico tu stesso. Su Ubuntu con netplan, lo 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]

Gli utenti di NetworkManager arrivano allo stesso stato con nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, poi nmcli con up "Wired connection 1". Applica netplan con netplan try al primo tentativo invece che con netplan apply; un gateway digitato male toglie la macchina dalla rete e ti lascia a cercare una console.

Mantieni comunque una prenotazione corrispondente. Non è ridondante. La voce registra l’indirizzo lato router e impedisce al server DHCP di assegnare quell’indirizzo a un dispositivo ospite se qualcuno allarga il pool più avanti.

Un indirizzo LAN stabile non è un endpoint pubblico

Punta il port forward su 192.168.50.10 e la regola sopravvive a ogni cambiamento lato LAN. Non ti dà un indirizzo internet stabile. Il tuo IP pubblico appartiene all’ISP e può spostarsi a una riconnessione o a un cambio di modem, ed è a questo che serve il DNS dinamico.

Dietro un NAT di livello operatore non c’è alcun IPv4 pubblico da inoltrare, e nessuna prenotazione ne crea uno. Controlla la pagina WAN del router prima di ogni altra cosa: se l’indirizzo è in un intervallo condiviso, l’inoltro in entrata non può funzionare, per pulita che sia la prenotazione.

Il terzo indirizzo è il pool del tunnel, spesso qualcosa come 10.8.0.0/24. Quegli indirizzi esistono solo dentro il tunnel e non compaiono mai sulla LAN. Confonderli con l’indirizzo LAN del server è il modo in cui una porta finisce inoltrata a un client che è online solo finché è connesso.

Controlla il percorso nell’ordine in cui si rompe

Inizia dal router. Confronta la voce della tabella dei lease con l’obiettivo della prenotazione; se il server ha preso un indirizzo del pool, l’identificatore è sbagliato, e ip link show sull’host ti dà il valore da confrontare.

Poi l’host. ip -4 addr show eth0 dovrebbe riportare l’indirizzo e il prefisso attesi. Un secondo indirizzo sulla stessa interfaccia di solito significa che DHCP sta ancora girando accanto alla tua configurazione statica.

Poi l’inoltro. Conferma che la destinazione sia ancora uguale all’indirizzo che hai appena verificato, e conferma che qualcosa sia in ascolto con ss -lntp. Un inoltro verso una porta chiusa dall’esterno sembra esattamente un inoltro rotto.

Termina dall’esterno, su un telefono con il Wi-Fi spento. Quell’unico test separa «l’indirizzo locale è sbagliato» da «la raggiungibilità pubblica è rotta», i due problemi che questa configurazione continua a mescolare.

Annota i tre indirizzi, LAN, pubblico e pool del tunnel, e segna quale sistema possiede ciascuno. Quando il mese prossimo una connessione fallirà saprai quale ispezionare invece di cambiare tutti e tre insieme.