Come spostare un server VPN Raspberry Pi su Ethernet

Spostare il Pi dal Wi-Fi a un cavo sembra un lavoro di cinque minuti, e lo resta solo se tratti il passaggio come quattro impostazioni separate invece di una. Il nome dell’endpoint che i tuoi client contattano può restare esattamente lo stesso mentre l’indirizzo sotto cambia. Quello che si rompe davvero è un listener fissato al vecchio indirizzo, un inoltro delle porte ancora puntato al lease wireless, o un percorso di ritorno che esce dall’interfaccia che pensavi di aver ritirato. Questa guida tiene aperto un percorso di ripristino a ogni passo, così un passaggio fallito costa solo un riavvio.

Annota i quattro responsabili prima di scollegare qualsiasi cosa

Quattro impostazioni decidono se il passaggio sopravvive: l’indirizzo del Pi, l’indirizzo di binding OpenVPN, la destinazione di reindirizzamento del router e il percorso che prendono le risposte. Annota tutti e quattro prima di toccare il cavo, perché una volta scomparso il lease wireless non puoi più leggere i vecchi valori dalla macchina. L’interfaccia via cavo non eredita il profilo wireless, e su Bookworm l’indirizzo vive in NetworkManager mentre Bullseye lo tiene in dhcpcd.conf. Una prenotazione che fissava l’indirizzo MAC wireless non dice nulla su eth0. Tratta il nuovo indirizzo come un’assegnazione nuova che ha bisogno della propria prova.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

Il listener è il secondo responsabile. Se il servizio è stato avviato con un indirizzo di binding specifico, il socket muore con la vecchia interfaccia; se collega tutti gli indirizzi, il socket sopravvive e la regola del router diventa l’unica cosa che resta da sistemare.

La destinazione di reindirizzamento e il percorso di ritorno sono i responsabili che la gente salta. Un inoltro che punta ancora a 10.42.7.24 manda gli handshake in arrivo a un indirizzo che il Pi non ha più, così i client scadono senza nessuna riga di log sul server. Il percorso di ritorno conta quando entrambi i collegamenti sono brevemente attivi, perché il Pi risponde dall’interfaccia che la tabella di routing preferisce, e non sempre è quella su cui è arrivato il pacchetto. La ricerca di rotta qui sotto mostra quale sorgente sceglie il kernel.

Leggi il socket reale prima di fidarti del nuovo indirizzo

I file di configurazione descrivono l’intenzione e il socket descrive la realtà. Chiedi al servizio in esecuzione a cosa è collegato invece di fidarti della configurazione che ricordi. Il manuale di OpenVPN 2.6 definisce --local come binding a un indirizzo e nota che ometterlo collega ogni interfaccia.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

Leggi la colonna dell’indirizzo locale invece della colonna dello stato. Una riga che mostra 10.42.7.24:1194 significa che il socket è fissato all’indirizzo che stai per rimuovere, mentre 0.0.0.0:1194 o *:1194 significa che il demone seguirà da solo il cambio di interfaccia. Se l’indirizzo è fissato, modifica il profilo e riavvia l’unità invece di riscrivere a mano il socket attivo, poi conferma che il servizio raggiunge ancora i suoi file di certificato e chiave.

Percorri lo spostamento in un ordine che ti mantenga raggiungibile

L’ordine qui conta più della velocità. Porta su il collegamento via cavo mentre quello wireless funziona ancora, conferma il nuovo indirizzo e il percorso di ritorno, poi ritira il profilo wireless. Quella sequenza tiene aperta una sessione funzionante finché il sostituto non è provato.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

Il primo comando risponde se eth0 ha ricevuto l’indirizzo che intendevi, e il secondo stampa l’indirizzo di origine che il kernel userebbe per una destinazione esterna, quindi eseguilo prima e dopo la modifica. Se quell’origine è ancora l’indirizzo wireless, il collegamento via cavo non è ancora il percorso preferito e il test dall’esterno fallirà per una ragione che non ha nulla a che vedere con OpenVPN. Correggi la preferenza di routing prima di toccare l’inoltro.

Con entrambi i collegamenti attivi, il Pi può preferire la rotta predefinita wireless perché è stata installata per prima o perché il collegamento via cavo ha una metrica più alta. Su Bookworm il controllo supportato è ipv4.route-metric sulla connessione, e su Bullseye l’equivalente è una riga metric specifica dell’interfaccia in dhcpcd.conf. Degrada il collegamento wireless invece di disattivarlo, così il percorso di ripristino resta a un comando di distanza.

Prova il tunnel dall’esterno, non dalla LAN

Una connessione VPN che funziona dal divano dimostra meno di quanto sembri. Il traffico da dentro la LAN verso l’indirizzo pubblico passa attraverso regole hairpin o di riflessione che i router implementano in modo incoerente, quindi un test LAN riuscito può convivere con un percorso esterno rotto. Usa un telefono con dati mobili, o qualsiasi host fuori dalla rete, per il test di accettazione. Mantieni il tentativo LAN come diagnostica opzionale separata.

Poi leggi il log nell’ordine in cui arrivano i pacchetti. Niente di niente significa che l’handshake non ha mai raggiunto il Pi, quindi la destinazione di reindirizzamento o il firewall dell’host è sbagliata. Un handshake che parte e si blocca indica chiavi, certificati o MTU. Una sessione che si completa e cade di solito significa il percorso di ritorno o una seconda rotta predefinita, e la riga di log del client Initialization Sequence Completed ti dice che il tunnel stesso è salito.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

Se nel log del server non appare nulla mentre il client riprova, smetti di leggere la configurazione di OpenVPN e torna alla destinazione di reindirizzamento. La cattura risponde alla domanda dell’arrivo in pochi secondi, e i pacchetti in ingresso senza risposta restringono il problema alla rotta.

Mantieni un ripristino in un passaggio e ritira il profilo wireless

Lascia installato il profilo wireless finché la disposizione via cavo non ha superato un riavvio. nmcli con show elenca i nomi dei profili che ti serviranno, e un profilo eliminato va ricostruito a memoria nel momento peggiore. Annota il nome dell’interfaccia, il metodo di indirizzamento e la metrica accanto agli altri quattro valori. Un ripristino che puoi digitare da una nota vale più di uno che devi ricostruire.

Ritirare la dipendenza wireless è un cambio di proprietà invece di un’eliminazione. Impostando connection.autoconnect no si mantengono intatte le credenziali e la cronologia degli indirizzi mentre si impedisce al Pi di ricollegarsi a una rete da cui ti sei allontanato.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

Prima di considerare il lavoro finito, conferma quattro cose: la destinazione di reindirizzamento corrisponde all’indirizzo via cavo, il listener è sopravvissuto a un riavvio, un client dall’esterno completa un handshake, e il Pi risponde ancora sull’indirizzo via cavo dopo un riavvio. Un riavvio è il modo più economico per intercettare un’assegnazione che esisteva solo nel kernel in esecuzione. Se una delle quattro fallisce, riporta su il profilo wireless con sudo nmcli con up e confronta i valori annotati con quelli attivi.