Cosa impedisce davvero route-nopull di OpenVPN al server di inviare

Hai messo route-nopull in un profilo client per evitare che il tunnel inghiottisse la tua rotta predefinita, e ora la sottorete dell’ufficio è irraggiungibile mentre il client dice ancora di essere connesso. Entrambe le osservazioni sono vere e nulla è fallito. Il flag dice al client di saltare le rotte e le voci DHCP che il server invia, un’istruzione più stretta di quanto la maggior parte delle persone si aspetti quando lo aggiunge. Quello che resta è un tunnel funzionante senza opinioni su quali destinazioni debbano usarlo.

Quel divario è l’intera decisione di cui tratta questo articolo. O è il server a descrivere la rete, o è il client, e il flag affida quel compito al client senza farne nulla per te.

Cosa spegne il flag al momento della connessione

Un client OpenVPN che tira normalmente riceve dal server dopo l’autenticazione un pacchetto: rotte, un reindirizzamento del gateway predefinito, server DNS e alcune direttive di regolazione. Con route-nopull in vigore il client accetta ancora la sessione, verifica ancora i certificati, negozia ancora cifrari e keepalive, e alza ancora l’interfaccia. Ciò che scarta è l’applicazione delle righe route inviate e delle righe dhcp-option inviate, DNS incluso.

La confusione nasce da un indicatore verde accanto a un’applicazione morta. Il tunnel esiste; la mappatura delle destinazioni su quel tunnel no. Nulla nel pannello di stato del client distingue «connesso e instradante» da «connesso e inerte», perché dal punto di vista del tunnel sono lo stesso stato.

Perché un tunnel vivo può comunque non instradare nulla

L’interfaccia compare con il proprio indirizzo e, su un collegamento punto a punto, spesso non ha nulla di più specifico di una rotta host verso il peer. Una sottorete privata diventa raggiungibile solo quando qualche rotta punta a quell’interfaccia con il prefisso giusto, e con l’invio disattivato quella rotta non arriva mai. Anche il profilo scaricato di solito non può aiutare, perché è stato scritto partendo dal presupposto che il server avrebbe fornito esattamente queste informazioni. Ecco perché l’interfaccia può sembrare sana mentre la sottorete resta al buio.

Leggere il profilo, quindi, dimostra ben poco. Leggi lo stato in esecuzione, sulla macchina connessa:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Un indirizzo senza rotta di sottorete nel secondo comando è la firma di questo problema. Il terzo comando risponde poi alla domanda che interessa davvero agli utenti, perché riporta l’interfaccia che il kernel sceglierebbe per una destinazione concreta invece dell’elenco che speravi usasse. Se risponde attraverso il tuo collegamento fisico, il tunnel non è affatto nel percorso.

La risoluzione dei nomi fallisce per una ragione collegata, non separata. Le voci dhcp-option DNS inviate vengono saltate dallo stesso flag, quindi le query per host interni vanno al resolver che la rete locale ha fornito. Quel resolver non ha una zona per l’ufficio, quindi la query fallisce o restituisce una risposta pubblica, e il guasto sembra un problema del server quando è un problema di configurazione del client. Testare un indirizzo prima di un nome è ciò che separa le due cose.

Scegliere tra il flag e un filtro di prefisso

Le due opzioni risolvono forme diverse dello stesso reclamo, ed è la scelta sbagliata a produrre lo stato connesso-ma-inutile. Una sostituisce del tutto la politica inviata, mentre l’altra la modifica per prefisso. La tabella dà la versione breve, e il paragrafo successivo copre la parte che coglie di sorpresa.

pull-filter è un comparatore di prefissi con tre verbi, quindi può accettare una famiglia di righe, ignorarle in silenzio o rifiutare del tutto la connessione quando compare un prefisso. È quest’ultimo comportamento che vale la pena conoscere: una regola di rifiuto trasforma un disaccordo di politica in un handshake fallito invece che in un’omissione silenziosa. Il manuale di OpenVPN 2.6 elenca i prefissi accettati e la semantica esatta di ogni verbo.

Una via di mezzo comune è rifiutare solo redirect-gateway e lasciare che le rotte dell’ufficio e il DNS arrivino come previsto. Questo mantiene l’invio funzionante per le parti che il server capisce meglio di te, evitando al tempo stesso l’unica riga che prenderebbe il controllo della tua rotta predefinita.

Aggiungere rotte e un resolver a mano

Se mantieni il flag, il profilo deve dire quello che avrebbe detto il server. Le direttive route lato client si applicano dopo che la connessione è stabilita, quindi funzionano accanto al flag invece di essere bloccate da esso. Mettile nel profilo, non in una riga di comando interattiva, altrimenti la prossima riconnessione non riprodurrà lo stato funzionante.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

La riga DNS sta in una posizione scomoda: è una direttiva lato client, ma alcuni client la applicano solo tramite l’integrazione DNS della piattaforma, che può sovrascriverla quando il collegamento cambia. Su un host systemd, impostare il resolver direttamente sull’interfaccia del tunnel è più prevedibile che sperare che il client vinca la gara di priorità:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Il dominio di instradamento conta quanto l’indirizzo. Senza di esso, le query per nomi pubblici possono essere inviate anche al resolver interno, e qualsiasi resolver interno che rifiuta la ricorsione romperà la navigazione lasciando funzionante la zona privata. Con esso, solo i nomi sotto quel suffisso vengono instradati al resolver del tunnel e tutto il resto segue il collegamento fisico.

Verificare il risultato: indirizzo, nome e percorso esterno

Tre test separano i guasti possibili. Recupera l’indirizzo privato per IP, poi lo stesso host per nome, poi un normale sito pubblico. Un IP che funziona con un nome che fallisce indica il resolver; un IP che fallisce con un nome che funziona indica l’instradamento; se falliscono entrambi di solito il tunnel non è nel percorso.

Poi guarda verso l’esterno invece che verso l’interno. La rotta dell’endpoint del tunnel deve sopravvivere al cambiamento, e qualsiasi blocco deve essere limitato al tunnel senza catturare l’endpoint. Un client che continua a navigare dopo la caduta del tunnel è un problema di politica, non di instradamento, e non comparirà in nessuno dei tre test sopra.

Scrivi l’elenco finale nella documentazione del profilo: le rotte, il resolver, i domini e il motivo per cui ciascuno esiste. Una riconnessione che riproduce la stessa tabella è l’unica prova che la politica locale è completa. Se le applicazioni continuano a fallire con il tunnel attivo e tutti e tre i test superati, il prossimo posto da guardare è la classe dei problemi connesso-ma-offline invece dei certificati già verificati.