Cosa succede davvero quando avvii una VPN su Linux

Premete connetti e tre cose cambiano su una macchina Linux: appare un'interfaccia, vengono installate le rotte e il resolver inizia a rispondere in modo diverso. La maggior parte degli errori di configurazione deriva dal fatto che una di queste tre cose accada senza le altre, o da due programmi che non sono d'accordo su chi le possiede. Capire la sequenza spiega il guasto più in fretta della lettura dell'output di log di un client.

Un'interfaccia appare prima che qualsiasi cosa funzioni

Un client di tunnel apre un'interfaccia virtuale e le consegna i pacchetti. Un dispositivo TUN trasporta pacchetti IP, ciò di cui ha bisogno una VPN instradata; un dispositivo TAP trasporta frame Ethernet, ciò di cui ha bisogno un progetto in bridge. Il modulo del kernel fornisce il dispositivo, e il client lo possiede finché dura la sessione.

Il fatto che l'interfaccia salga non equivale al funzionamento del tunnel. Può esistere con un indirizzo mentre il peer è irraggiungibile, ed è per questo che l'elenco delle interfacce è il primo controllo e non l'ultimo. Un dispositivo che si dichiara attivo descrive la visione del kernel di un collegamento virtuale, non la disponibilità del peer a rispondere.

Lasciate stare la modalità di interfaccia fornita. Passare un profilo TUN a TAP non trasforma un server instradato in uno in bridge, e di solito produce una connessione che si stabilisce e non inoltra nulla.

Le rotte le installa chi possiede il tunnel

Le rotte sono il secondo cambiamento, e la loro proprietà conta più del loro contenuto. Un profilo NetworkManager, un'unità systemd e un client avviato a mano possono tutti installare rotte, e due di loro che lo fanno insieme producono una tabella che nessuno saprà spiegare in seguito.

ip -br addr show
ip route show
ip -6 route show

Un profilo a tunnel completo sostituisce la rotta predefinita; un profilo a tunnel diviso aggiunge rotte più specifiche e lascia in pace la predefinita. Entrambi sono normali, e il secondo è il motivo per cui eliminare una rotta predefinita è un pessimo primo test su una macchina che amministrate da remoto. Rimuoverla è anche il modo più rapido per perdere la sessione che usate per risolvere il problema.

Leggete la tabella invece di supporre. Una rotta più specifica o una regola di policy può mandare il traffico nel tunnel mentre la rotta predefinita punta ancora all'interfaccia fisica, cosa che sembra contraddittoria finché non leggete l'intera tabella. Quella combinazione è normale per il tunnel diviso e confonde chi si aspetta che una sola riga descriva il progetto. Cercate la rotta che corrisponde alla vostra destinazione reale, non quella che corrisponde al diagramma.

Il resolver cambia mano

Il DNS è il terzo cambiamento e quello che più probabilmente è gestito in un punto che non avete guardato. Su un desktop, NetworkManager può spingere le impostazioni del resolver per connessione. Su un sistema che usa systemd-resolved, le impostazioni vengono applicate per collegamento e /etc/resolv.conf può essere uno stub o un collegamento simbolico anziché un file che dovreste modificare.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Se una modifica manuale al file del resolver sparisce dopo una riconnessione, quello è il segnale per trovare il componente che lo mantiene e cambiare invece il profilo. Modificare il file generato è un cambiamento che una riconnessione cancellerà.

I nomi privati di solito hanno bisogno del resolver interno e dei domini di ricerca forniti dall'operatore. Sostituirlo con un resolver pubblico può rompere proprio la risorsa per cui la VPN esiste, e il sintomo sembra un guasto di routing e non di DNS. Provate il nome e l'indirizzo separatamente, perché uno che funziona e l'altro che fallisce vi dice esattamente dove guardare. Quell'unico confronto risparmia un'ora di debug delle rotte.

Un gestore per connessione

Il formato del profilo decide quale programma può usarlo. Un profilo OpenVPN richiede OpenVPN o un plugin compatibile, e una configurazione WireGuard ha un formato proprio con chiavi del peer e prefissi consentiti. Una finestra di importazione non traduce l'uno nell'altro, qualunque cosa suggerisca l'estensione del file.

Scegliete un gestore e lasciategli possedere la connessione. Sollevare lo stesso tunnel con due strumenti rende ambigui la tabella delle rotte e il comportamento di riconnessione, e di solito vince il secondo che parte, in modi difficili da riprodurre.

Installate i pacchetti supportati dalla vostra distribuzione e ottenete il profilo dall'operatore. Trattatelo come una credenziale, perché di solito contiene una chiave privata o materiale equivalente, e conservatelo dove vivono gli altri vostri segreti. Un profilo lasciato in una cartella di download è una chiave lasciata su una scrivania.

Cosa controllare quando è attivo ma non funziona

Con l'interfaccia attiva e il client che riporta successo, lavorate verso l'esterno: la tabella delle rotte seleziona il tunnel per la destinazione, il resolver risponde per il nome privato e il lato remoto ha un percorso di ritorno. Ognuno ha un comando separato e un proprietario separato.

nmcli connection show --active
nmcli device status
wg show

Il riferimento di nmcli documenta i comandi di stato e connessione se vi serve l'insieme completo. Ciò che conta qui è la distinzione tra un profilo attivo e un dispositivo che trasporta traffico, perché i due possono contraddirsi.

Riconnettetevi una volta tramite lo stesso gestore prima di dichiarare l'installazione finita, e verificate che il DNS funzioni ancora dopo una disconnessione. Una configurazione che funziona solo fino al primo cambiamento di rete non è finita, sta semplicemente funzionando in questo momento.