OpenVPN continua a spingere route vecchie? Controllate cosa ha caricato

Aggiungete una rotta, riavviate il servizio, vi riconnettete e la tabella del client è esattamente come prima. Possono essere vere due cose diverse: il server non ha mai caricato la vostra modifica, oppure il client non ha mai installato ciò che ha ricevuto. Non hanno nulla in comune tranne il sintomo, quindi il primo passo è scoprire quale dei due casi avete.

Il confronto qui sotto parte dal processo verso l'esterno, perché il processo è l'unica autorità su quale file sia in vigore.

Il file che avete modificato e il file che il processo legge

Iniziate dall'unit e dalla riga di comando che ha prodotto. Su un host systemd, systemctl cat openvpn@server stampa la riga ExecStart, e un'unit di istanza di solito ricava il percorso di configurazione dal nome dell'istanza, quindi un demone avviato come openvpn@office legge un file diverso da uno avviato come openvpn@server. Confrontatelo con l'argv del processo in esecuzione. Uno strumento di gestione della configurazione aggiunge un altro modo di perdere la modifica: può scrivere un file corretto in un percorso che l'unit non menziona mai, e allora un deploy verde sembra non aver fatto nulla.

Le marche temporali lo risolvono in fretta: se il file è più recente dell'ora di avvio del processo, il processo non può averlo letto. Il firmware del router aggiunge un terzo caso, perché molti modelli tengono le impostazioni nella flash e ricostruiscono la configurazione durante l'avvio, il che rende la modifica di un file su disco lo strato sbagliato.

Cosa spinge il server e cosa installa il client

Una rotta spinta deve superare due filtri. Sul server deve stare nella configurazione caricata, non in un blocco commentato né in un file specifico per un client il cui nome non corrisponde. Sul client pull deve essere attivo e nessun pull-filter deve scartare l'opzione. Connettetevi con verbosity 4 e leggete le opzioni spinte che il client riporta: se la rotta compare in quella lista, il server ha fatto il suo lavoro ed è il client a scegliere di non installarla.

I file specifici per client sono una fonte frequente di confusione. Un file nominato secondo il common name del certificato spinge opzioni solo a quel client, e una differenza di un carattere ferma lo push in silenzio, senza errore da nessuna delle due parti. Il server registra il common name che ha visto al momento della connessione, quindi confrontate quel valore con il nome del file, non con quello che credete sia il nome del client.

Il prefisso spinto e la rotta di ritorno sono problemi diversi

Un client che ignora deliberatamente redirect-gateway per mantenere il proprio percorso internet locale crea una seconda lacuna, senza rapporto. Le sonde del server raggiungono l'indirizzo del tunnel e le risposte non arrivano mai, perché una risposta indirizzata all'IP del tunnel del server viene instradata tramite il normale gateway predefinito del client. La rotta di sottorete spinta non ha colpa qui; ciò che manca è una rotta che rimandi il traffico della rete del tunnel del server giù per il dispositivo tunnel.

Aggiungere quella rotta sul client corregge le risposte alle sonde avviate dal server. Non sostituisce la rotta di sottorete spinta, e vale anche il contrario, perché le due descrivono direzioni di viaggio opposte.

Confrontate le tabelle su entrambi i lati

Dopo ogni modifica, riconnettetevi e leggete la tabella del client per il prefisso spinto e per il dispositivo tunnel. Poi provate in entrambe le direzioni: dal client a un host della sottorete spinta, e da quell'host di ritorno al client. Una rotta che esiste ma non trasporta traffico significa una di tre cose: il lato remoto non inoltra, un firewall scarta il flusso, oppure la risposta non ha via di ritorno.

Tenete insieme tre identificatori: il percorso di configurazione, il nome dell'unit o dell'istanza e l'identità del client con cui avete provato.

Questi tre trasformano la prossima occorrenza in un controllo di cinque minuti invece di un'altra indagine, e sono ciò che serve a un collega quando il tunnel diventa il problema di qualcun altro.

Un problema di rotte che sopravvive a un riavvio spesso non è affatto un problema di routing; il guasto sta a monte della tabella che continuate a leggere.