Server o client: quale unità OpenVPN su un Pi a doppio ruolo

Due processi OpenVPN girano su un Pi che accoglie sia utenti nomadi sia raggiunge un provider a monte, e non condividono quasi nulla oltre all’hardware. Uno ascolta i tunnel in ingresso mentre l’altro si collega verso l’esterno. Ognuno legge la propria directory, e ognuno ha il proprio modo di fallire. Riavviare quello sbagliato è il modo più comune con cui una correzione del client finisce per scuotere l’ascoltatore.

Abbina il nome dell’unità alla directory che carica

Upstream 2.6 fornisce due unità modello, [email protected] e [email protected]. Il modello server parte in /etc/openvpn/server e carica %i.conf da lì. Il modello client parte in /etc/openvpn/client. Un’istanza chiamata roaming può esistere in entrambi i posti contemporaneamente, come server e come client, con due configurazioni non correlate e nessun legame tra loro oltre alla stringa.

Chiedi a systemd invece che al filesystem, perché i pacchettizzatori aggiungono file aggiuntivi che possono cambiare la directory di lavoro o gli argomenti che riceve il binario.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Il primo comando elenca ogni unità istanziata, comprese quelle che hanno fallito e sono rimaste caricate. Il secondo stampa il file dell’unità insieme a qualsiasi override. Il terzo è il modo più rapido per vedere i due fatti che decidono la questione: la directory in cui parte il processo, e il percorso di configurazione che gli è stato passato.

Decidi dalla direzione dei pacchetti, non dal nome dell’interfaccia

Un’istanza server possiede un socket in ascolto e accetta connessioni. Il suo trasporto cifrato è input locale e output locale sul Pi, mentre il traffico che inoltra per gli utenti segue il percorso di inoltro e risponde a un altro insieme di regole. Un’istanza client non ha ascoltatore in quel senso: si collega a un pari, quindi il suo trasporto cifrato è output locale verso lo strato inferiore.

Questa differenza ti dice a cosa appartiene una regola. Una regola che corrisponde a un’interfaccia dentro una catena di inoltro permette solo il traffico che il routing ha già selezionato; non seleziona mai la rotta. Quando i pacchetti di un utente nomade escono per la strada sbagliata, la catena da ispezionare è forward, non output.

Guarda i socket prima di teorizzare. Un server legato a udp/1194 mostra un socket in ascolto. Il client mostra un’associazione all’indirizzo del provider e nulla in ascolto.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

La rotta predefinita di un’istanza può catturare le risposte dell’altra

Un redirect-gateway spinto dal client a monte installa una rotta predefinita che compete con tutto il resto della macchina, comprese le risposte che il server invia agli utenti nomadi. OpenVPN fa un’eccezione per il proprio indirizzo di pari così che il tunnel resti raggiungibile, ma quell’eccezione non dice nulla di un telefono su una rete d’albergo.

Il sintomo è di solito asimmetrico. L’handshake si completa, il client segnala connesso, e il traffico muore dopo il primo pacchetto di risposta. Il routing policy basato sulla sorgente, o un marchio di pacchetto impostato sull’istanza server con --mark, tiene separati i due flussi; nessuno dei due è un insieme completo di regole da solo, ed entrambi richiedono rotte valide nella tabella che scelgono.

Prova la decisione locale invece dello stato del tunnel, perché il kernel sceglie la sorgente e l’interfaccia prima che OpenVPN veda il pacchetto.

ip route get 203.0.113.44
ip rule show

Riavvia un ruolo e dimostra che l’altro è sopravvissuto

L’ordine conta quando entrambi i ruoli dipendono dallo stesso strato inferiore. Riavvia il client per primo se la rotta a monte deve esistere prima che il traffico utente possa essere inoltrato, e riavvia il server per primo quando cambi solo il suo ascoltatore o il suo pool. In ogni caso conferma entrambe le unità dopo, perché un riavvio fallito può lasciare l’altro ruolo in funzione su uno stato obsoleto.

Scrivi la condizione di arresto prima della modifica: la perdita del tunnel a monte blocca gli utenti nomadi o ricade sull’uplink proprio del Pi? Anche DNS e IPv6 hanno bisogno di una risposta esplicita, perché un resolver spinto spesso sopravvive alla rotta che lo ha reso utile.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Accetta la modifica solo quando tre cose valgono insieme: una nuova connessione in ingresso si completa, un’applicazione inoltrata raggiunge la sua destinazione attraverso l’uscita prevista, e i due processi segnalano ancora il loro pari atteso. Se una delle tre fallisce, hai cambiato l’istanza sbagliata o la rotta sbagliata, e il passo successivo è rileggere l’unità invece di riavviare qualcos’altro.