Un solo server TAP o più? Client OpenVPN su un bridge

Più client TAP non richiedono un processo server, una porta UDP e un dispositivo TAP dell’host per ciascuno. Un server OpenVPN in modalità Ethernet può accogliere molti client autenticati e collegarli a un unico bridge, e questo è il modo documentato per estendere un segmento di livello 2. Il progetto a processo singolo è quello documentato dal manuale ed è di solito il valore predefinito corretto.

La vera domanda è se questi client debbano condividere quel segmento. Il numero di processi non risponde, perché le proprietà di isolamento derivano dalla topologia e non da quanti demoni sono in esecuzione. Il resto di questo confronto riguarda le due topologie e ciò che ciascuna rende facile.

Due architetture, non due impostazioni

Un deployment TUN con routing assegna a ogni client un collegamento punto a punto nel dominio di routing del server. I broadcast si fermano al server, i client non vedono i frame degli altri e il traffico tra client, se esiste, deve essere instradato e filtrato in modo esplicito.

Un deployment TAP con bridging rende i client membri di un unico segmento Ethernet. Vedono i broadcast, possono risolversi a vicenda con ARP e dipendono dalla politica del bridge e del firewall anziché dal routing per restare separati. È utile quando i client devono apparire come se fossero collegati allo stesso switch.

Il confronto riguarda quindi ciò che i client devono raggiungere, non le prestazioni. Scegliete prima il livello, poi decidete quanti processi lo servono.

Che cosa fa l’helper server-bridge

L’helper server-bridge configura la modalità Ethernet multi-client. La sua forma con pool di indirizzi prende il gateway, la netmask e un intervallo dedicato all’interno della sottorete con bridge, per esempio un gateway su 192.168.50.1 con un pool da 192.168.50.160 a 192.168.50.199.

Riservate quell’intervallo al di fuori di qualsiasi altra assegnazione DHCP o statica. L’helper assegna indirizzi da lì, ma non si coordina con un altro assegnatore sullo stesso segmento, e due pool sovrapposti producono indirizzi duplicati che sembrano errori di connettività casuali. Scrivete l’intervallo riservato nel piano degli indirizzi del sito così la persona successiva non lo riutilizza. Un commento nella configurazione del server è un pessimo sostituto di quel registro.

Esiste una forma con proxy DHCP per deployment in cui un server esterno distribuisce gli indirizzi. Ha i suoi prerequisiti, e mescolare le due forme produce esattamente il conflitto che la documentazione segnala. Scegliete un solo assegnatore per la sottorete con bridge.

L’isolamento non deriva dal numero di processi

Otto processi OpenVPN collegati allo stesso bridge senza restrizioni condividono ancora un unico dominio di broadcast. I client possono inviarsi ARP attraverso il bridge, e il numero di listener non ha cambiato nulla in proposito.

Se il requisito è che gruppi di client non si vedano a livello 2, il progetto ha bisogno di bridge separati o collegamenti VLAN, con le regole di accesso che li accompagnano. È una decisione di progettazione di rete, ed è la stessa sia che sia coinvolto un processo server sia otto. Il filtraggio del bridge può limitare parte del traffico, ma non crea domini di broadcast separati. Trattatelo come un complemento alla segmentazione, non come un sostituto.

Se il requisito è solo che i client raggiungano determinati servizi IP, un progetto TUN con routing è di solito più semplice del bridging con filtraggio. Ogni client ottiene il proprio collegamento, e la politica vive nelle regole di routing e del firewall invece che all’interno del bridge.

Quando più processi restano giusti

Processi separati possono essere giustificati da esigenze operative: backend di autenticazione diversi, autorità di certificazione diverse, cicli di aggiornamento separati o insiemi di opzioni incompatibili. Sono ragioni reali e sono indipendenti dal numero di client.

Se ne usate diversi, date a ciascuno il proprio listener e la proprietà del dispositivo e coordinate gli intervalli di indirizzi. Due server che credono entrambi di possedere lo stesso pool sullo stesso bridge finiranno per distribuire lo stesso indirizzo.

Poi verificate il progetto con più client contemporaneamente. Controllate che gli indirizzi siano unici, che il traffico previsto tra client funzioni e che una coppia che non deve comunicare non possa farlo. Un ping riuscito da un solo client non mette alla prova nulla del progetto multi-client.

Leggete il bridge e la modalità del server dall’host in esecuzione prima di fidarvi dello schema. La configurazione che conta è quella che il kernel e il demone hanno effettivamente caricato, ed è anche quella che un revisore può controllare.