VPN instradata o LAN in bridge per un collegamento tra filiale e laboratorio

Ci sono due modi per far raggiungere un laboratorio domestico a una filiale, e la differenza non è un’impostazione. Puoi instradare tra prefissi distinti, così ogni sede mantiene il proprio dominio di broadcast, oppure puoi mettere in bridge le due LAN in una sola, così broadcast e traffico di scoperta si comportano come se tutti fossero nella stessa stanza. L’instradamento è il progetto che sopravvive al contatto con una rete reale. Il bridge è il progetto che rende facile la prima settimana e interessante il primo guasto. Il confronto qui sotto riguarda ciò che ciascuno ti dà e quanto costa, seguito da come rendere testabile la versione instradata.

Due modi per collegare, un compromesso ovvio

Un collegamento instradato tratta il laboratorio domestico come una rete remota con il proprio indirizzamento. La filiale chiede il prefisso del laboratorio, il tunnel trasporta quei pacchetti, e il gateway del laboratorio risponde dalla propria sottorete. Nulla della tabella ARP della filiale cambia, e nulla dell’ambito DHCP del laboratorio raggiunge la filiale.

Un collegamento in bridge estende un solo dominio di livello 2 su entrambe le sedi. I protocolli di scoperta funzionano, i dispositivi compaiono automaticamente, e ogni broadcast, ogni richiesta ARP e ogni pacchetto multicast è ora un candidato ad attraversare il tunnel, cioè una grande quantità di traffico trasportata da protocolli progettati per un segmento locale e non per una WAN con un’altra MTU e un tempo di andata e ritorno variabile.

Che cosa ti dà l’instradamento

Il primo vantaggio è il raggio dei danni. Un loop, un server DHCP indesiderato o un’ondata di broadcast resta nella sede che l’ha prodotto, perché un router non inoltra i broadcast. Il secondo è la chiarezza dell’indirizzamento: il prefisso della filiale e quello del laboratorio sono distinti, quindi la destinazione di un pacchetto ti dice quale sede deve rispondere, e una regola del firewall può dire «filiale verso sottorete del laboratorio» invece di «ovunque verso ovunque».

Il terzo è che corrisponde a ciò che il tunnel trasporta davvero. Una policy IPsec è una coppia di prefissi, e il percorso di inoltro su ciascun lato è normale routing IP con l’inoltro abilitato sul gateway:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Quello a cui rinunci è la scoperta tramite broadcast. È una perdita reale, e va sostituita deliberatamente invece di essere aggirata mettendo tutto in bridge.

Quanto costa il bridge

Il bridge deve trasportare frame di livello 2 su un tunnel, il che significa un incapsulamento come GRE o VXLAN su IPsec invece di un semplice tunnel basato su policy. Una volta che esiste, le due sedi condividono un dominio di guasto. Lo spanning tree vede il tunnel come un collegamento, il traffico broadcast consuma banda del tunnel, e qualsiasi dispositivo che presuppone un segmento a bassa latenza si comporta male in modi difficili da attribuire da entrambe le estremità.

Rimuove anche il controllo degli indirizzi che ti tiene onesto. Con un unico prefisso piatto, un indirizzo duplicato non è un errore di routing ma due host che si rubano silenziosamente il traffico, e prefissi sovrapposti tra una filiale e un laboratorio sono comuni negli allestimenti da laboratorio domestico, quindi il bridge non risolve quel conflitto; lo distribuisce.

L’argomento di sicurezza è quello che di solito decide. Un bridge estende il segmento su cui operano i protocolli link-local, quindi un dispositivo nella filiale può parlare con dispositivi del laboratorio che non avrebbero mai dovuto essere raggiungibili dall’esterno. Se il laboratorio ha un hypervisor, una console di storage e un’interfaccia di gestione sulla stessa rete piatta, ora è un solo segmento insieme alla filiale.

Nomi senza broadcast

Il motivo per cui le persone mettono in bridge è di solito la scoperta: una stampante, un lettore multimediale o un host del laboratorio che non compare mai in un elenco. La risposta instradata è un servizio di nomi. Pubblica gli host del laboratorio in una zona che il resolver della filiale può raggiungere, poi lascia che gli utenti si connettano per nome invece di scansionare la rete. È più lavoro all’inizio e molto meno lavoro a ogni cambiamento futuro.

La scoperta multicast è il caso più difficile, e merita precisione. Protocolli come mDNS usano il multicast link-local, che i router non inoltrano per impostazione predefinita, quindi un host del laboratorio assente da un elenco di scoperta può essere ancora raggiungibile al suo indirizzo documentato. Se un servizio specifico richiede davvero il multicast, pianifica quel solo protocollo, con un riflettore o una regola di inoltro mirata, invece di mettere in bridge l’intera LAN come riparazione generale.

Anche un riflettore non è una vittoria gratuita. Importa lo stesso traffico loquace che cercavi di evitare, un servizio alla volta, e ha bisogno di un proprietario che noti quando un dispositivo inizia ad annunciare più di prima. Scegliilo per servizio, e scrivi perché. Annota quale servizio ne aveva bisogno e che cosa annuncia, perché un aggiornamento del firmware può cambiare quell’elenco senza dirlo a nessuno.

Rendi testabile il progetto instradato

Scegli un obiettivo, per esempio un’interfaccia web del laboratorio su una propria sottorete dei server, e dimostralo in entrambe le direzioni. Da un host della filiale, conferma l’indirizzo e il servizio in ascolto in locale, poi connettiti attraverso il tunnel e ripeti. Un tunnel che è su dimostra che i gateway sono d’accordo; non dimostra nulla sul firewall dell’host o sulla rotta di ritorno.

Il gateway normale del laboratorio ha bisogno di una rotta di ritorno verso il prefisso della filiale, a meno che il progetto traduca deliberatamente la sorgente, e il firewall del server stesso deve accettare l’intervallo remoto consentito. Nessuno dei due viene configurato da un tunnel riuscito. Le note sull’inoltro di strongSwan descrivono il percorso dei pacchetti che deve funzionare su ciascun lato.

Poi prova anche una destinazione negata. Un utente della filiale che ha bisogno di una sola applicazione non ha bisogno della console dell’hypervisor, e l’unico modo per sapere che la policy è reale è provare proprio ciò che dovrebbe rifiutare. Annota i prefissi, la dipendenza dal resolver e i risultati dei test, e un cambiamento futuro in una delle due sedi può essere esaminato in pochi minuti invece di essere ricostruito a memoria.