Server e client OpenVPN su un solo host: perché i client cadono

Aggiungete un profilo client a una macchina che esegue già un server VPN e il servizio originale è la prima vittima. Il nuovo tunnel può non stabilirsi mai, oppure salire mentre i client esistenti del server smettono silenziosamente di ricevere risposte. Due collisioni producono entrambi i risultati: un pool di tunnel già in uso e una rotta predefinita installata dalla metà client nuova che copre tutta la tabella. Nessuna delle due produce un messaggio di errore di OpenVPN, ed è per questo che il guasto viene letto come un problema del server.

Una macchina, due ruoli e due risposte incompatibili su dove debbano andare le risposte.

Stesso pool, due server: chi vince

Ogni istanza di server ha bisogno della propria sottorete di tunnel. Copiare una riga come server 10.8.0.0 255.255.255.0 nella seconda configurazione dà alle due istanze lo stesso prefisso, e il risultato è o un rifiuto a partire o una competizione silenziosa in cui i client di un server ricevono indirizzi che l’altro considera anch’esso suoi. Porte UDP diverse e nomi di dispositivo diversi non aiutano, perché nessuno dei due tocca lo spazio degli indirizzi. Cambiate il secondo pool e cambiatelo ovunque le rotte lo menzionano.

Elenchiamo cosa è attivo prima di modificare: ip -4 addr show elenca i dispositivi di tunnel, ss -lunp elenca gli ascoltatori e systemctl list-units nomina le unità. Uno sguardo agli indirizzi del tunnel stabilisce se i pool si scontrano.

Cosa aggiunge il profilo client alla tabella

La metà client scrive rotte appena si connette. redirect-gateway def1 divide la rotta predefinita in 0.0.0.0/1 più 128.0.0.0/1, entrambe instradate attraverso il nuovo dispositivo, insieme a una rotta host verso il server remoto deliberatamente fissata all’interfaccia fisica. Quel fissaggio esiste perché il tunnel conservi un percorso per il proprio trasporto. Tutto il resto, comprese le risposte che il server locale deve ai propri client, ora segue la nuova rotta predefinita ed esce dal collegamento remoto.

Quindi la seconda collisione non è un tunnel rotto. È un tunnel che funziona nel posto sbagliato della tabella.

Tre modi per tenere separati i ruoli

La correzione meno invasiva tiene la rotta predefinita fuori dal profilo client: route-nopull più righe route esplicite per i prefissi remoti, così la tabella locale cambia solo dove l’avete chiesto. Il passo successivo è una regola di policy che esenta la sottorete del tunnel locale, lasciando che le risposte ai client locali escano dall’interfaccia da cui sono arrivate anche quando esiste una rotta predefinita. La più completa è uno spazio dei nomi di rete separato per il ruolo client, che rimuove del tutto la tabella condivisa e costa un secondo contesto di routing da mantenere.

Qualunque percorso scegliate, l’eccezione deve nominare la sottorete del tunnel locale e non la LAN. La risposta che il server locale invia ha come destinazione un indirizzo di tunnel, quindi un’eccezione a forma di LAN non la riguarda mai.

Quale delle due istanze è colpevole

Fermate l’istanza client e riesaminate i client originali. Un recupero immediato significa routing, non server. Riportate su il client e tracciate una singola risposta con ip route get a cui vengono dati sia un indirizzo sorgente sia uno di destinazione, il che mostra il percorso che il kernel sceglierebbe, poi osservate l’interfaccia che i pacchetti usano davvero con tcpdump -ni any port 1194. Il file di stato del server, scritto ogni pochi secondi tramite la direttiva status, contiene l’elenco dei client connessi e i contatori di byte in entrambe le direzioni.

Leggete quei contatori l’uno contro l’altro. Il traffico che esce e non torna mai è una risposta di routing, non un problema di handshake.