Perché due sedi con la stessa sottorete non sono un’unica LAN

Due uffici usano entrambi 192.168.77.0/24, e qualcuno propone un tunnel perché siano un’unica rete. La frase sembra semplice e nasconde tre progetti diversi: due LAN indipendenti che collidono, un segmento Ethernet esteso di proposito su una WAN e un assetto proxy ARP che risponde per indirizzi remoti. Quale dei tre avete decide cosa fa un host con il pacchetto, e la risposta è visibile prima che il gateway VPN sia coinvolto.

L’host decide prima del router

Un host con indirizzo 192.168.77.10/24 confronta la destinazione con il proprio prefisso. Tutto ciò che sta dentro quel prefisso è sul collegamento diretto, quindi l’host risolve direttamente l’indirizzo di livello collegamento della destinazione. Tutto ciò che resta fuori va al gateway predefinito.

Questa decisione avviene nello stack dell’host, non nel tunnel. Una rotta aggiunta sul gateway non può salvare un pacchetto che l’host non invia mai lì.

Così, quando 192.168.77.20 esiste solo nella sede remota, l’host locale lo chiede via ARP e non riceve risposta. La stretta di mano VPN può essere perfettamente sana mentre questo fallisce. Il guasto sembra un host morto più che un problema di routing. Riconoscere questa firma fa risparmiare un’ora di debug del tunnel.

ARP è una domanda di collegamento locale

ARP chiede chi possiede un indirizzo su questo collegamento, e la risposta deve venire da qualcosa che sente il broadcast. Un router all’altro capo di un tunnel IPsec non lo sente, a meno che il progetto non renda le due sedi un unico dominio di broadcast.

Due dispositivi con lo stesso indirizzo peggiorano la cosa: nemmeno una risoluzione riuscita può dire quale abbia risposto.

L’indirizzamento duplicato non è un bug di routing e nessuna rotta lo corregge. O le sedi vengono rinumerate in prefissi distinti, o diventano di proposito un unico dominio di livello collegamento.

Un segmento esteso trasporta frame, non rotte

Un tunnel che trasporta Ethernet e collegato a bridge rende entrambe le sedi parte di un unico dominio di livello collegamento. I broadcast ARP arrivano dall’altra parte, e ogni bridge apprende quali indirizzi MAC stanno dove. La documentazione del bridge di Linux descrive quel confine di inoltro basato sui MAC.

Qui il gateway remoto non fa affatto routing tra due sottoreti identiche. I frame attraversano uno strato sottostante che instrada IP per conto proprio, mentre i bridge prolungano la conversazione Ethernet.

Il prezzo è un raggio d’impatto più ampio. Il flooding verso destinazioni sconosciute, i loop, l’assegnazione DHCP e l’indirizzamento univoco richiedono tutti un piano che copra entrambe le sedi. Quando la WAN cade, gli host perdono traffico che considerano locale. Il filtraggio sul bridge e le regole VLAN possono limitare ciò che attraversa, ma il trasporto ancora non promette che ogni frame di controllo di collegamento locale arrivi.

Il proxy ARP è un terzo progetto

Un router può rispondere all’ARP per un indirizzo remoto e poi instradare verso di esso. Questo fa apparire l’host remoto sul collegamento diretto per il mittente senza estendere un dominio di broadcast.

È uno strumento più stretto del bridging: dipende dall’inoltro, dalle rotte di ritorno e da un proprietario chiaro per ogni indirizzo.

Non rende nemmeno instradabili protocolli arbitrari che non siano IP, e non riproduce un dominio di broadcast Ethernet. Usatelo quando il requisito è esattamente quella sostituzione, non come scorciatoia per una rinumerazione rinviata.

Scegliete in base al requisito, poi verificate

Per il normale accesso applicativo tra uffici, prefissi distinti e rotte esplicite danno un confine più chiaro. Fate bridging quando il requisito è davvero adiacenza di livello collegamento. Rinumerate quando l’unica ragione del prefisso condiviso è che nessuno l’ha ancora fatto.

Confermate quale progetto avete davvero chiedendo a un host cosa fa con la destinazione:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Un risultato di collegamento diretto con una voce di vicino fallita indica un percorso di livello collegamento mancante. Un risultato via nomina il gateway e sposta la domanda sul routing. Su un bridge, controllate il database di inoltro per vedere se il MAC è stato appreso attraverso il tunnel. Ogni output restringe la domanda di progetto invece di riaprirla.