Le rotte VPN importate differiscono dal client funzionante? Confronta entrambi

Un servizio privato risponde attraverso la VPN mentre il traffico internet ordinario si comporta in modo del tutto diverso rispetto alla macchina di un collega, e la tentazione è concludere che il client Ubuntu sia guasto. Questa conclusione salta un passaggio. Un’operazione privata funzionante e un percorso pubblico diverso sono due osservazioni, e la differenza di solito risiede nella politica di traffico installata da ciascun client, non nel client stesso.

Confrontare la configurazione salvata con lo stato effettivo della rete richiede tre comandi e risponde alla domanda che le supposizioni cercavano di risolvere.

Prima il profilo salvato, poi lo stato effettivo

Una connessione OpenVPN importata diventa un profilo NetworkManager a sé stante. Il file .ovpn da cui proviene smette di essere la fonte di verità nel momento in cui l’importazione termina, quindi modificarlo in seguito non cambia nulla nella connessione che stai usando. È il primo punto in cui il confronto va storto, e va storto in silenzio.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Leggi l’UUID quando i nomi coincidono; i nomi duplicati sopravvivono a reinstallazioni e ripristini di profili, e puoi passare un’ora a modificare la copia che non è in uso. I valori che vedi descrivono l’intento salvato: se il profilo può prendere la rotta predefinita, quali rotte sono state memorizzate e quali resolver e domini di ricerca richiede. Non descrivono ciò che è successo all’attivazione della connessione, perché un plugin o un push del server possono aggiungere stato che il profilo non menziona. Ecco perché conta il comando successivo.

Poi guarda cosa ha effettivamente fatto il sistema con quell’intento, comprese le regole di policy e ogni tabella, non solo quella principale. Le proprietà salvate sono input, e le tabelle installate sono il risultato.

ip -4 rule show
ip -4 route show table all

Due destinazioni, un confronto

Scegli una destinazione privata che funziona e una destinazione pubblica ordinaria, poi chiedi al kernel quale percorso prenderebbe ciascuna. Farlo su entrambe le macchine è ciò che trasforma una differenza vaga in una specifica.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

Gli indirizzi sono esempi da sostituire con i tuoi; conta la coppia, non i numeri. Confronta l’interfaccia, l’indirizzo sorgente e la tabella indicata in ciascun output. Quando la ricerca privata indica il tunnel e anche quella pubblica indica il tunnel, hai un tunnel completo e l’altro client potrebbe averne uno diviso, o il contrario.

Non pretendere che i due client stampino un testo identico. Un redirect-gateway def1 di OpenVPN è comunemente espresso come due rotte a mezzo prefisso invece di una predefinita, e un gestore che le mostra diversamente non è per questo sbagliato. Giudica la copertura, che è ciò che mostrano le ricerche, non la formattazione.

Dove i due client differiscono legittimamente

Le impostazioni predefinite dei client sono scelte di policy, ed è consentito che non siano d’accordo. Un prodotto può preferire un tunnel completo, un altro può mantenere la predefinita locale e instradare solo i prefissi privati, e un terzo può seguire ciò che il server ha inviato. Una differenza è un difetto solo quando contraddice il requisito che ti è stato dato.

Quindi confronta ogni client con l’intento approvato di tunnel diviso o completo, non l’uno con l’altro. Se il requisito è che il traffico privato usi il tunnel e il percorso internet locale resti locale, allora il tunnel completo è il bug e il tunnel diviso è corretto, indipendentemente da quale client abbia fatto cosa. Scrivi l’intento prima di guardare l’una o l’altra configurazione, altrimenti il primo client che esamini diventa silenziosamente lo standard.

Il DNS è un secondo asse e fallisce in modo indipendente. Una rotta corretta può comunque inviare query a un resolver che non può rispondere per la zona privata, e un resolver corretto non sistema una rotta sbagliata. Controlla entrambi, e considera un nome privato che si risolve mentre un indirizzo privato non lo fa come prova che i due livelli vengono risolti separatamente.

Mantieni pulito il confronto

Esegui un solo proprietario della connessione alla volta. Una sessione OpenVPN da riga di comando che gira accanto al profilo importato installa le proprie rotte e il proprio stato del resolver, e la miscela risultante non è il comportamento di nessuno dei due client. Smonta l’una prima di misurare l’altra. Riavvia se non sei sicuro di cosa stia ancora mantenendo stato, perché una rotta vecchia di un’ora sembrerà esattamente un problema di policy.

Mantieni fissato anche tutto il resto: lo stesso endpoint, lo stesso account, le stesse versioni software, la stessa rete. Un successo sul portatile Windows di un collega verifica un client diverso, un’integrazione del resolver diversa e forse un profilo server diverso, quindi non è una prova sul gestore Ubuntu.

Il riferimento alle impostazioni IPv4 di NetworkManager definisce con precisione never-default e le proprietà delle rotte salvate, e vale la pena leggerlo prima di modificare un valore gestito. E ricorda l’ambito di questo confronto: copre IPv4 e non dice nulla sulla corrispondente politica IPv6, che ha i propri valori predefiniti e il proprio modo di sorprenderti.