Rotta VPN mancante in NetworkManager: politica del profilo o script?
Il tunnel si connette e un prefisso non compare mai. Decidi tra politica del profilo, dati del plugin e un secondo proprietario della rotta prima di aggiungere uno script ausiliario.
Ti connetti, l'interfaccia del tunnel compare e un prefisso che ti serve semplicemente non è nella tabella. Il passo successivo di solito è la ricerca di uno script che lo aggiunga. Quella ricerca porta a risposte che incollano un assistente OpenVPN dentro un profilo, e metà di quelle risposte peggiora la situazione invece di migliorarla, perché una rotta mancante ha tre possibili proprietari e solo uno di essi è uno script mancante.
Decidi quale proprietario è responsabile prima di scrivere qualsiasi cosa.
Tre proprietari, un prefisso mancante
Il prefisso può mancare perché nessuno l'ha fornito, perché il profilo l'ha rifiutato o perché è stato installato in un posto che non stai guardando. Sono guasti diversi e hanno correzioni diverse.
Il primo è il più facile da verificare: il server o il plugin hanno mai offerto la rotta? Un backend che non ha mai ricevuto il prefisso non può installarlo, e uno script ausiliario non può inventare una raggiungibilità che il peer non ha mai descritto. Il secondo è la politica del profilo, che può sopprimere rotte che la connessione prenderebbe altrimenti. Il terzo è una tabella o una regola, che può tenere la rotta in un posto che la ricerca predefinita non consulta mai.
Un quarto proprietario sei tu, più avanti: uno script che aggiunge la rotta alla connessione ma non la rimuove alla disconnessione. Questo produce un prefisso che sopravvive al tunnel, punta a un'interfaccia morta e confonde la persona successiva che esegue il debug della macchina.
Leggi il profilo prima di aggiungere qualsiasi cosa
Parti dalle proprietà della connessione salvata. Leggile senza riversare segreti e usa l'UUID se il nome del profilo è ambiguo.
nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office
vpn.service-type ti dice quale backend possiede la connessione, e questo conta perché i dati del plugin sono specifici del backend. Una chiave accettata da un plugin non è un'istruzione supportata da un altro, quindi un frammento copiato dalla documentazione di un altro client non è prova di nulla.
ipv4.ignore-auto-routes e ipv4.never-default rispondono a domande diverse. Il primo può rifiutare rotte che la connessione prenderebbe altrimenti in automatico, e il secondo controlla se il profilo può diventare la rotta predefinita. Un profilo che ignora le rotte automatiche e non si basa su nient'altro si connetterà in modo pulito e non installerà quasi nulla.
ip -4 rule show
ip -4 route show table all
Quei due comandi risolvono la terza possibilità. Cerca il tuo prefisso in ogni tabella, non solo in main, e controlla se una regola di politica manda la ricerca pertinente altrove. Se il prefisso è in un'altra tabella e nulla la consulta, non hai una rotta mancante; hai una ricerca che non la raggiunge mai.
Ciò che uno script non può correggere
Aggiungere uno script ausiliario dà a vpn.data di NetworkManager un programma da eseguire. È un meccanismo reale, ed è quello sbagliato per la maggior parte di questi casi, perché lo script riceve il controllo dopo che la politica del profilo ha già deciso cosa accettare.
Il script-security di OpenVPN è l'altra confusione ricorrente. È un'impostazione di OpenVPN che stabilisce quali script il client può eseguire e cosa può mettere nel loro ambiente; il livello 3 consente di passare le credenziali attraverso l'ambiente, che è una decisione sulla gestione dei segreti e non una correzione del routing. Incollarlo in un profilo il cui backend non è OpenVPN, o alzarlo quando nessuno script ne ha bisogno, aggiunge esposizione senza aggiungere una rotta.
Poi c'è il riflesso del riavvio. Riavviare il servizio NetworkManager abbatte e ricostruisce ogni collegamento gestito, compreso quello attraverso cui sei connesso se lavori in remoto. È un'azione dirompente, non una diagnosi innocua, e su un server può essere la differenza tra una sessione che sopravvive e una che non sopravvive.
La decisione, in ordine
Poni tre domande in sequenza. Il peer ha fornito il prefisso, cosa che mostreranno il log del backend o il suo output di stato? Se sì, il profilo è configurato per accettare e installare rotte, o le sta sopprimendo? Se la rotta esiste da qualche parte, il percorso di ricerca è corretto per il traffico che stai testando?
Solo quando la prima risposta è sì, la seconda è sì e la terza è corretta uno script supplementare diventa difendibile, e anche allora dovresti chiedere se il backend supporta la rotta in modo nativo. La referenza delle impostazioni VPN documenta service-type e il dizionario dei dati specifico del plugin, ed è da lì che bisogna partire prima di dare per scontata l'esistenza di una chiave.
Dopo una correzione approvata, riconnettiti e prova la destinazione per indirizzo e poi per nome, quindi disconnettiti e riconnettiti per confermare che lo stato è ripetibile. Un proprietario, una tabella e una rotta che scompare con il tunnel è il risultato che vale la pena.