Il tuo pool VPN non è l'intervallo DHCP della LAN: perché si rompe

La scorciatoia tentante è assegnare ai client VPN indirizzi dello stesso intervallo usato dal server DHCP dell'ufficio, nella convinzione che tanto sia tutta una rete. Non lo è. Un tunnel instradato trasporta pacchetti unicast tra due estremi, mentre il pool della LAN esiste per rispondere alle richieste di broadcast su un segmento fisico. Riusare i numeri mette due assegnatori al comando di un solo spazio di indirizzi e lascia il percorso di ritorno indefinito.

Due assegnatori, uno spazio di indirizzi

Il server DHCP della LAN sa quali indirizzi ha affittato e a quale indirizzo MAC, e li difende con ARP. Il server VPN ha il proprio pool e non sa nulla di quei contratti. Nessuno dei due sbaglia; semplicemente non sono mai stati presentati.

Un indirizzo del pool della LAN che il server VPN assegna può già appartenere a una stampante. Ora due dispositivi rivendicano un indirizzo sullo stesso prefisso, e la tabella di inoltro dello switch decide quale risponde.

È il guasto che le persone incontrano per primo: un client che si connette con successo e poi raggiunge la macchina sbagliata, o raggiunge quella giusta a intermittenza.

Perché il router non distribuisce indirizzi VPN

Il rilevamento DHCP è un broadcast, e i broadcast si fermano a un confine instradato. A meno che il progetto non colleghi in bridge il tunnel o non esegua un relay DHCP con l'autorità corrispondente, la richiesta del client non raggiunge mai il server della LAN.

Perciò il server VPN assegna l'indirizzo da solo: un pool nella configurazione del server, un indirizzo per peer in un'installazione WireGuard, o un indirizzo spinto dal livello di autenticazione in un deployment IKEv2. Questi meccanismi sono indipendenti dal database dei contratti della LAN, ed è esattamente per questo che serve loro un intervallo proprio.

Lo stesso ragionamento spiega perché cambiare l'ambito DHCP non ripara un client VPN che non ottiene mai un indirizzo. Il client non interroga il server della LAN, e nessuna modifica dell'ambito lo indurrà a farlo.

La sovrapposizione si manifesta come conflitto, non come rete lenta

Due reti che condividono un prefisso senza un progetto supportato sono un problema diverso dalla doppia proprietà, e spesso vengono confuse. Se il pool VPN è un prefisso separato, la sovrapposizione conta solo quando una rotta manda il traffico dalla parte sbagliata. Se il pool sta dentro il prefisso della LAN, il conflitto è immediato e locale.

In pratica vedi risposte ARP dal dispositivo sbagliato, connessioni che si resettano a metà, e un client il cui indirizzo è rivendicato da qualcun altro. Niente di tutto ciò sembra un problema di routing, per questo la correzione viene applicata al livello sbagliato. Un contratto duplicato è facile da confermare e fastidioso da sopportare. Sopravvive anche ai riavvii, perché entrambi gli assegnatori continuano a insistere sullo stesso indirizzo.

Il percorso di ritorno è un problema a parte

Anche con un pool pulito e distinto, gli host della LAN devono sapere come rispondere a un client. Il loro gateway predefinito è il router, e il router ha bisogno di una rotta per il pool che punti al server VPN, a meno che il progetto non traduca invece il traffico del client.

Leggi il percorso in entrambe le direzioni prima di cambiare qualcosa. Sul gateway, chiedi quale interfaccia userebbe il kernel per un indirizzo di client; sul client, chiedi quale rotta usa per un indirizzo della LAN.

Questi comandi mostrano la decisione di inoltro sul gateway e le voci di vicinato che rivelano un duplicato:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Se il primo comando risponde con l'interfaccia del tunnel, la rotta di ritorno esiste. Se risponde con l'interfaccia della LAN, il router crede che il client sia sul cavo e tenterà un ARP per lui.

Esistono progetti in bridge, ma vanno scelti

Collegare in bridge un tunnel alla LAN è un progetto reale, usato quando i client devono ricevere broadcast o essere scoperti da protocolli che presuppongono un solo segmento. Richiede che il server possieda quel comportamento di bridging e la gestione degli indirizzi che lo accompagna.

Ciò che non funziona è imitare il risultato copiando i numeri. Un pool condiviso senza bridge ti dà il conflitto senza la scoperta, che è il peggio di entrambe le disposizioni.

Scegli il livello tre con un pool distinto, a meno che l'applicazione non abbia davvero bisogno del segmento, e documenta il pool perché il prossimo amministratore non riusi l'intervallo DHCP per pura pulizia.