Indirizzo VPN contro lease DHCP della LAN: chi assegna l’IP del tunnel?

Collega il client e guarda la scheda di rete invece dell’icona Wi-Fi. Un indirizzo come 10.80.0.14 può stare su un tunnel mentre nessun server DHCP della LAN dell’ufficio ha mai registrato quel lease. Il processo che ha scelto il numero decide da dove inizia la diagnosi.

Sul client tutto sembra uguale: un indirizzo IPv4, una maschera, a volte un gateway predefinito. La differenza appare solo quando chiedi chi risponde di quell’indirizzo e chi ne tiene un registro.

Leggi l’indirizzo del tunnel dal lato client

Windows mostra la differenza se leggi tutto il blocco e non la prima riga. ipconfig /all stampa una descrizione della scheda, un indirizzo fisico e una riga DHCP. Una scheda di connessione remota PPP o IKEv2 riporta normalmente DHCP come disattivato, perché la connessione ha negoziato il proprio indirizzo durante la chiamata invece di prenderlo in lease da un server della LAN. Una scheda di tunnel con DHCP attivo è insolita e merita un’indagine a parte.

Linux distribuisce le stesse informazioni su due strumenti. ip -4 addr show dev tun0 fornisce l’indirizzo e la lunghezza del prefisso. nmcli -f IP4 connection show work rivela se il valore è arrivato dal profilo di connessione, da uno scambio DHCP sul collegamento o da una configurazione spinta. WireGuard è il caso più chiaro, perché wg-quick applica la riga Address del file di configurazione quando l’interfaccia compare e nessun peer assegna nulla al momento della connessione.

Anche il prefisso dice qualcosa. Un /32, o una maschera di 255.255.255.255, significa che il gateway prevede di instradare verso un solo indirizzo host, mentre una maschera più ampia suggerisce una sottorete sul collegamento da qualche parte dietro il tunnel.

Che cosa trasporta il payload di configurazione IKEv2

IKEv2 ha un meccanismo dedicato a questo compito. Il payload di configurazione descritto nella RFC 7296, sezione 3.15.1 trasporta attributi come INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS e le loro controparti IPv6. Il client invia un attributo di lunghezza zero quando non ha preferenze, e il risponditore restituisce il valore che vuole venga usato. Quello scambio viaggia dentro IKE_AUTH, già cifrato, quindi nessuna diffusione DHCP attraversa mai il tunnel.

Ne seguono due conseguenze. Primo, l’indirizzo è scelto dal risponditore o da qualunque backend di autorizzazione consulti, per questo un pool può vivere sul gateway, in una risposta RADIUS o in una mappatura del provider di identità. Secondo, l’attributo DNS è separato dall’attributo dell’indirizzo. Ricevere 10.80.0.14 non dice nulla su quale resolver è tornato, né se ne è tornato uno.

L’attributo della maschera di rete è facoltativo in pratica. Molte installazioni restituiscono solo un indirizzo e lasciano che il client installi una rotta verso l’host, per questo lo stesso pool può sembrare un /32 su un client e un /24 su un altro.

Dove si scontrano un ambito DHCP della LAN e un pool VPN

Il guaio inizia quando entrambi gli assegnatori puntano allo stesso intervallo. Un server DHCP per 10.20.30.0/24 non sa nulla di un pool VPN configurato per 10.20.30.128/25, quindi nulla gli impedisce di dare 10.20.30.140 in lease a una stampante mentre il gateway consegna lo stesso indirizzo a un client remoto. La collisione resta silenziosa per giorni e poi emerge come duplicato intermittente.

Un progetto instradato da sede a sede evita la collisione per costruzione. Un host nella filiale mantiene l’indirizzo che gli ha dato il server DHCP locale. Le interfacce di tunnel dei due gateway portano i propri indirizzi di collegamento, e la tabella di routing decide come viaggiano i pacchetti. Gli indirizzi dei client in accesso remoto sono una terza categoria e non vanno mescolati con gli indirizzi di collegamento del gateway.

Pontare il tunnel sulla LAN elimina quella separazione. Se il progetto richiede davvero un solo dominio di broadcast, l’estremo VPN deve partecipare alle stesse decisioni di assegnazione del server DHCP, tramite un relay o una fonte autorevole condivisa, invece di emettere indirizzi per conto proprio.

Verifica quale processo possiede l’indirizzo

Dimostra la proprietà prima di cambiare un ambito. Sul client annota indirizzo e prefisso. Sulla LAN cerca nel database dei lease. Sul gateway elenca i pool che è configurato a distribuire. Un indirizzo trovato nel file dei lease appartiene a un server DHCP, il che significa che il tunnel è pontato o relayato; un indirizzo trovato solo nel pool del gateway appartiene all’estremo del tunnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Annota quattro cose quando la risposta è chiara: quale componente assegna l’indirizzo del client, quale intervallo è riservato a esso, come il traffico di ritorno raggiunge quell’intervallo e quali risorse lo accettano. Queste quattro voci trasformano una riga di scheda virtuale in un fatto operativo.

Ripeti il controllo per l’attributo DNS finché sei lì. Un pool che distribuisce indirizzi senza resolver lascia il client sul suo DNS locale, che è un guasto diverso da un pool che distribuisce un indirizzo che la LAN già usa.