I client OpenVPN non si vedono tra loro: sottorete o net30?

Due guasti non correlati producono la stessa lamentela. Nel primo, un client non raggiunge un altro nemmeno per indirizzo del tunnel, perché gli indirizzi non sono in un'unica sottorete o il server non inoltra il traffico tra peer. Nel secondo, ping funziona e l'elenco dei dispositivi dell'applicazione resta vuoto, perché la scoperta si basa su broadcast che un tunnel di livello 3 non può trasportare. Un solo ping li separa, e la correzione di ciascuno non assomiglia affatto a quella dell'altro.

Un solo ping divide il problema in due

Da un client, fate ping all'indirizzo del tunnel dell'altro client, non al suo nome e non al suo indirizzo LAN. Se fallisce, il problema è l'inoltro o l'indirizzamento e la scoperta è irrilevante finché non viene corretto. Se riesce, l'inoltro funziona già e ciò che manca è broadcast o risoluzione dei nomi.

ip addr show tun0

Leggete l'interfaccia del client prima di ogni altra cosa, perché la maschera di rete nomina la topologia. Una /24 o un'altra maschera di sottorete significa un pool condiviso; una /30 con indirizzo peer significa la vecchia disposizione punto a punto, dove ogni client ha esattamente un vicino, il server.

net30 contro sottorete, letto dal lato client

Con net30 il server assegna un blocco piccolo per client, quindi non esiste una rotta verso l'indirizzo del tunnel di un altro client se il server non la inoltra. Con la sottorete l'intero pool è una rete, ogni client può indirizzare ogni altro e il server inoltra tra loro. Per questo una configurazione del server può sembrare sana mentre i ping tra peer falliscono: nulla è rotto, i client semplicemente non sono in un'unica rete. Il client vede un collegamento funzionante e un indirizzo peer che non risponde, il che si legge come un firewall ma è una disposizione di indirizzamento.

Cambiare la direttiva è una modifica lato server più un riavvio, e vale per la connessione successiva, non per le sessioni già attive. Riconnettete i client prima di giudicare il cambiamento. Se un'appliance rigenera la configurazione da un'interfaccia web, annotate la direttiva, il file e la data, e fate la modifica tramite l'interfaccia quando esiste, perché una ricostruzione sovrascriverà una modifica manuale al salvataggio successivo.

client-to-client è un cancello separato

Anche dentro un'unica sottorete il server scarta i pacchetti che arrivano da un client e sono indirizzati a un altro, a meno che client-to-client sia impostato. Quella parola chiave rende il server un inoltro per il traffico tra peer invece di un endpoint che lo accetta soltanto. È la seconda condizione che le persone trascurano dopo aver corretto la topologia.

Questo non si estende al broadcast. L'impostazione inoltra unicast tra client; non trasforma il tunnel in un segmento condiviso, e nessuna quantità di essa consegnerà una query di scoperta multicast a ogni peer.

TUN contro TAP, e cosa può trasportare ciascuno

Mettere in bridge un dispositivo tap nella LAN colloca i client remoti nel dominio broadcast dell'ufficio, il che risolve del tutto la scoperta. Il prezzo sono le piattaforme che non implementano TAP, un bridge che deve esistere sul server e un dominio di guasto in cui una tempesta broadcast sul cavo dell'ufficio raggiunge ogni portatile remoto.

Per due o tre workstation che hanno bisogno di risoluzione dei nomi, una voce hosts o un indirizzo unicast costa molto meno di un bridge. Ricorrete a TAP quando un protocollo che non potete sostituire dipende dalla scoperta di livello 2, e non prima.

Client della stessa sottorete senza bridge

Assegnare un indirizzo dall'intervallo della LAN non mette il client sul cavo. Il server instrada tra tunnel ed Ethernet, quindi l'ARP per quell'indirizzo si ferma all'interfaccia del server e il resto della LAN non scopre mai dove abita.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP chiude quella lacuna facendo rispondere il server per conto del client. Per un intervallo, parpd gestisce le voci man mano che i client entrano ed escono, mentre il sysctl net.ipv4.conf.eth0.proxy_arp=1 risponde per tutto ciò che è instradato altrove, il che è abbastanza ampio da creare sorprese proprie su un segmento trafficato.

Qualunque strada scegliate, togliete NAT tra il tunnel e il cavo. Una regola MASQUERADE nasconde proprio la domanda di indirizzamento a cui cercate di rispondere. Lascia anche alla persona successiva una topologia su cui non può ragionare dal lato client.

Prima di cambiare qualcosa, catturate un tentativo sul server con tcpdump -ni tun0 e confermate se il pacchetto del peer arriva. Che arrivi e venga scartato punta a client-to-client; che non arrivi mai punta alla topologia o all'instradamento. Il manuale di OpenVPN 2.6 documenta entrambe le parole chiave e la topologia predefinita, cosa che vale la pena confrontare con la vostra versione prima di copiare una riga da un post di un forum.

• L'interfaccia tun mostra una maschera di pool invece di una coppia peer /30.
• Un ping diretto all'altro indirizzo del tunnel riesce prima di testare la scoperta.
• La configurazione del server include client-to-client ogni volta che i peer devono scambiarsi pacchetti.
• Nominate il protocollo di scoperta che state testando invece di dire che l'applicazione fallisce.
• Usate TAP solo se ogni piattaforma client del gruppo lo supporta.
• Tenete NAT fuori dal percorso tra tunnel e LAN quando conta la raggiungibilità nella stessa sottorete.