DHCP attraverso una VPN: pontare il broadcast o inoltrarlo?

Un nuovo portatile dall’altro lato del tunnel non ottiene un indirizzo, mentre lo stesso portatile funziona in sede. Il primo sospetto abituale è che il tunnel blocchi DHCP. Più spesso il broadcast non ha mai avuto un percorso: un client non configurato invia a 255.255.255.255, e un router IP ordinario non inoltra quel pacchetto. Il tunnel fa esattamente ciò che fa un tunnel instradato.

Due progetti possono cambiarlo, e non sono equivalenti. Uno trasporta il broadcast; l’altro inoltra la richiesta.

Il broadcast non attraversa mai il router

Un client DHCPv4 senza indirizzo invia da 0.0.0.0 all’indirizzo di broadcast limitato sulle porte UDP 67 e 68. Quel pacchetto resta sul suo collegamento per progetto. Un router che lo inoltrasse inonderebbe ogni segmento che serve.

Quindi un tunnel instradato da sito a sito collega il relay a un server. Non estende il dominio di broadcast del client, e nessuna regola del firewall lo farà.

Che cosa estende davvero un tunnel pontato

Una VPN deliberatamente pontata può trasportare il broadcast Ethernet nella sua topologia supportata, e allora DHCP può passare come traffico locale. È un’opzione reale, ma è una scelta di progetto di livello 2. State estendendo il dominio di guasto e il confine di accesso insieme al broadcast.

Il pontaggio cambia anche ciò che una tempesta di broadcast, una scansione ARP o un server DHCP fraudolento possono raggiungere. Se non colleghereste la sede remota allo stesso switch, non pontate il tunnel solo per distribuire indirizzi. Provate quel raggio d’impatto prima di abilitarlo.

È una decisione più grande del fornire un indirizzo, e va presa deliberatamente.

Inoltrate invece la richiesta

La risposta abituale è un relay sulla rete locale del client. Riceve il broadcast, lo trasforma in una richiesta unicast e mette il proprio indirizzo nel campo indirizzo del gateway. Il server risponde a quell’indirizzo del relay.

Per una sede remota di esempio, il relay si trova sulla LAN della sede e si raggiunge il server tramite la VPN del sito. Configurate l’ambito per quella sede, le identità del relay e del server, e il percorso di ritorno completo. Consentire UDP 67 attraverso il tunnel non dice al server quale pool usare.

Un relay che inoltra ma non riceve mai risposta è di solito un problema di percorso di ritorno. Controllate la rotta verso l’indirizzo del relay prima di cambiare l’ambito.

Separate DHCP da ARP e dall’indirizzamento del tunnel

DHCP viaggia su UDP/IP. Su Ethernet, un host può anche usare ARP per verificare se un indirizzo candidato è già in uso. Quel controllo di conflitto è un’operazione locale al collegamento separata, non il trasporto dei messaggi DHCP. Dire che DHCP è essenzialmente ARP è sbagliato; dire che i due non sono mai correlati è troppo ampio.

Un client VPN può anche ottenere il proprio indirizzo di tunnel dal protocollo VPN o dal pool del server stesso invece che da un broadcast DHCP. Un’opzione il cui nome contiene DHCP può descrivere impostazioni del client inviate, non un pacchetto DHCP inoltrato. Controllate il pool del server prima di supporre che DHCP sia coinvolto.

Annotate la rete destinataria, il proprietario dell’assegnazione, l’ambito, l’esistenza di un relay e il comportamento atteso durante un’interruzione. Poi provate un nuovo lease e un rinnovo attraverso quel modello. Se due siti possono servire lo stesso pool non gestito, avete un conflitto in attesa del primo portatile itinerante.