OpenVPN iroute o rotta del kernel: quale manca?

Un pacchetto per 10.77.20.0/24 prende due decisioni separate su un server OpenVPN: il sistema operativo deve consegnarlo all’interfaccia VPN, e OpenVPN deve sapere quale client connesso possiede quel prefisso. Una rotta del kernel assente lo scarta prima del tunnel, una rotta del peer assente lo scarta dopo. I due guasti sembrano identici dalla LAN remota, e diagnosticare quale avete richiede un comando su ciascun lato.

Nel classico percorso dati in spazio utente, la rotta del kernel porta il pacchetto al processo del tunnel e iroute dice a quel processo quale peer deve riceverlo. Nessuna sostituisce l’altra, e una configurazione che ne porta solo una sembrerà ragionevole fino al primo ping.

Due decisioni, non una rotta

Immaginate un collegamento da sede a sede in cui 10.77.20.0/24 sta dietro un solo client. La rotta del kernel del server, per esempio ip route add 10.77.20.0/24 dev tun0, invia i pacchetti corrispondenti al dispositivo del tunnel. OpenVPN consulta poi la propria tabella interna, costruita dalle voci iroute nella directory di configurazione del client, per decidere quale connessione peer li riceve. Senza la rotta del kernel il pacchetto non raggiunge mai il processo, e senza la rotta del peer lo raggiunge e non va da nessuna parte.

Questa separazione si dimentica facilmente, perché una sola riga di rotta in un profilo client può sembrare che faccia entrambi i lavori. Non li fa: spingere una rotta dice ai client cosa inviare attraverso il tunnel, mentre iroute dice al server chi possiede un intervallo di indirizzi dietro un client. Vivono in file diversi, sono letti da lati diversi e falliscono in direzioni opposte.

Dove va iroute e cosa dice

La voce va in un file per client chiamato come il common_name del client, sotto client-config-dir, come iroute 10.77.20.0/24. La corrispondenza del nome del file non è estetica: OpenVPN cerca l’identità autenticata e legge il file con esattamente quel nome, quindi un file chiamato site-a ha effetto solo per un client il cui nome comune è site-a. Aggiungete ccd-exclusive se i client privi di tale file devono essere rifiutati del tutto, che è l’impostazione giusta quando ogni client è un gateway di sede. Tenete un file per gateway e nominatelo come il soggetto del certificato che emettete davvero.

Provate la voce dal server prima di dare la colpa alla LAN remota. Il file di stato elenca i client connessi con i loro nomi comuni, e un server eseguito con --verb 4 registra l’installazione di iroute quando il peer si connette. Se non compare nulla al momento della connessione, il file è nella directory sbagliata o nomina l’identità sbagliata.

La trappola: file presente, identità errata

Un iroute dall’aspetto corretto ma agganciato al peer sbagliato fa perdere più tempo di un file mancante, perché tutto sul disco sembra a posto. La rinomina dei certificati, i nomi comuni duplicati e username-as-common-name che cambia l’identità effettiva lo producono tutti. Controllate quale identità il server ha autenticato invece di quella che vi aspettavate: l’output di stato è autorevole, mentre il nome del file è solo una chiave di ricerca.

Una rotta può sopravvivere al suo proprietario. Le rotte statiche e le voci iroute descrivono un prefisso, non una garanzia di disponibilità, perciò il traffico può continuare a essere instradato verso un peer attualmente disconnesso.

Completate il percorso oltre il peer

La proprietà del peer è la metà del percorso, non la fine. Il client deve inoltrare i pacchetti dal tunnel alla propria LAN, il che significa inoltro IP abilitato su quell’host e una regola del firewall che consenta il transito. Gli host della LAN remota hanno bisogno di un percorso di ritorno per l’indirizzo del tunnel: o una rotta che punta al gateway, o una progettazione NAT deliberata sul lato client. Confermate l’impostazione di inoltro sul client con sysctl net.ipv4.ip_forward invece di supporre un valore predefinito della distribuzione.

Se altri client VPN devono raggiungere quella sottorete, la disposizione cresce ancora: il server ha bisogno di client-to-client, e quei client devono instradare il prefisso attraverso il tunnel. Nulla di ciò è implicato dalla tabella di routing del server stesso.

Verificate una destinazione da una sorgente reale invece che dal server stesso. Un ping da un host LAN non correlato verso un host dietro il client mette alla prova il percorso di ritorno, la regola di inoltro e la proprietà del peer in un solo gesto, mentre una stretta di mano riuscita dimostra solo l’identità. Poi disconnesse il peer proprietario e annotate cosa fa la rotta, perché quella risposta è la vostra modalità di guasto.