Dove va la rotta in OpenVPN: sul client o sul server?
Una rotta nuda nella configurazione del server cambia il server, non il client. Scegliete il file del client, un push globale o un push per un solo client, e verificate cosa è arrivato.
Aggiungete route 10.60.0.0 255.255.255.0 alla configurazione del server, riavviate, ricollegate un portatile, e la sottorete resta irraggiungibile da quel portatile. La riga è stata accettata, il servizio è partito pulito e nulla nel registro sembra sbagliato. Quello che è successo è che la rotta è stata installata sulla macchina che avete modificato: il gateway ora crede di poter raggiungere quel prefisso, mentre al client non è stato detto nulla. La collocazione è tutta la questione, e ci sono quattro posti in cui la stessa riga può vivere.
I quattro posti e chi riceve ciascuno
Una rotta può essere aggiunta dalla configurazione del client stesso, offerta a ogni client tramite un push globale, offerta a un solo client tramite un file specifico, oppure scritta nel contesto di routing del server stesso.
Questi quattro casi usano una sintassi quasi identica e producono risultati completamente diversi. I primi tre influenzano ciò che un client invia nel tunnel; il quarto influenza il modo in cui il server raggiunge una rete, utile quando il server stesso ha bisogno di un percorso e dannoso quando viene scambiato per una distribuzione.
Decidete quale dei quattro volete prima di scrivere la riga, poi confermate il destinatario.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Perché la rotta nuda sul server sorprende
La configurazione del server è il primo posto in cui guardano gli amministratori, e una direttiva di rotta lì si legge come un'affermazione sulla rete VPN. Non lo è. OpenVPN la tratta come un'installazione locale di rotta sulla macchina che esegue il demone, esattamente lo stesso tipo di modifica che fareste con ip route e poi dimentichereste.
La distribuzione richiede che la rotta venga inviata con push, e il push richiede che il client la tiri. Un client avviato con le opzioni tirate disattivate ignora completamente l'offerta. Controllate entrambe le estremità di quella stretta di mano prima di riscrivere il file del server, perché il registro del server non si lamenterà: dalla sua parte l'offerta è stata inviata. Una rotta accettata entra in vigore anche solo alla connessione successiva, mai nella sessione in cui siete già.
Quando vedete le due operazioni come separate, il guasto smette di essere misterioso: il server raggiunge il prefisso, il client no, e entrambe le affermazioni sono vere contemporaneamente.
File per client e l'identità con cui corrispondono
Un file specifico per un client prende il nome dall'identità che il server ha autenticato, che per impostazione predefinita è il nome comune del certificato. Un nome di connessione amichevole in un client desktop non è quel valore, e una discordanza produce un file che non viene mai letto.
Controllate la directory che il server usa realmente, poi confermate che il nome del file corrisponda esattamente all'identità autenticata, comprese maiuscole e minuscole.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Dentro quel file la rotta va comunque inviata con push, perché il contesto per client è un insieme di opzioni applicate alla sessione di quel client, non una tabella di routing locale. Una rotta nuda lì ha lo stesso problema di una rotta nuda nel file globale.
Il file del client e lo strumento che lo gestisce
Una rotta inserita nella configurazione del client viene installata quando quel client si connette e rimossa quando si disconnette, che è il ciclo di vita corretto per una destinazione statica.
Se un gestore di rete possiede il profilo, può importare quelle opzioni una volta e poi conservare la propria copia. Modificare in seguito il file scaricato non cambia nulla, il che è una causa comune di "la rotta c'è ma non si applica".
Controllate il profilo attivo invece del file scaricato, e controllate le impostazioni importate che il gestore mostra. Poi connettetevi e chiedete al sistema quale percorso usa un indirizzo specifico, invece di supporre che il tunnel abbia vinto perché la rotta esisteva in un file di testo.
Verificate sul client, poi controllate il percorso di ritorno
Chiedete alla tabella di routing del client la destinazione, non a quella del server. Una ricerca per un singolo host dentro il prefisso basta a mostrare l'interfaccia e il prossimo salto che verranno usati.
ip route get 10.60.0.10Se la ricerca punta al tunnel, la distribuzione ha funzionato e il problema rimanente è altrove. Se punta al gateway predefinito, la rotta non è stata installata, è stata filtrata da un'opzione lato client, o appartiene a un profilo che il client non usa.
Supponete che la distribuzione abbia funzionato e che ancora nulla risponda: allora controllate l'inoltro sul gateway, la rotta di ritorno dell'altro lato e qualsiasi firewall tra i due. Una rotta sceglie un percorso, non concede accesso.