La porta 1194 è già in uso: a chi appartiene quel socket OpenVPN?

Avviate due volte lo stesso profilo server e il secondo processo esce con un errore di indirizzo già in uso per la porta 1194. Nel caso comune è stato l’avvio diagnostico a creare il conflitto, e l’istanza originale continua a servire i clienti perfettamente. Questa storia spiega gran parte di queste segnalazioni, e vale la pena riconoscerla prima di riavviare qualsiasi cosa. È anche la versione più economica da risolvere.

L’errore descrive un binding locale e nulla oltre. Non è prova che un fornitore blocchi la porta, che un client abbia inviato la password sbagliata o che la catena di certificati sia rotta.

Leggete l’errore di binding esatto

Due errori di questa famiglia significano cose diverse, e confonderli vi manda allo strato sbagliato. «Indirizzo già in uso» dice che un altro socket possiede l’endpoint richiesto. «Indirizzo non disponibile» dice che l’indirizzo richiesto non esiste ancora su questo host, il che è un problema di prontezza e non un duplicato.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Copiate il testo dell’errore prima di cambiare qualsiasi cosa, inclusi l’indirizzo e la porta che nomina. Un servizio che attende la comparsa di un’interfaccia registrerà ripetutamente il secondo errore e poi si collegherà correttamente quando l’indirizzo esiste; un servizio che registra il primo errore non avrà mai successo finché il duplicato non è risolto. Annotare quale dei due avete visto non costa nulla e risparmia una ricerca di interfacce sprecata.

Inventariate il socket, non la porta

Un numero di porta è un inventario incompleto. L’endpoint è un trasporto, una famiglia di indirizzi, un indirizzo locale e una porta, tutto dentro un unico spazio dei nomi di rete. Un listener UDP e un listener TCP sullo stesso numero sono socket diversi, e due processi sullo stesso numero in spazi dei nomi diversi non si incontrano mai.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Eseguite prima il trasporto che il profilo usa davvero. Poi guardate la colonna dell’indirizzo locale invece del solo numero: un binding wildcard copre ogni indirizzo locale, quindi un secondo processo che chiede un indirizzo specifico può entrare in collisione anche se le stringhe stampate differiscono. Le opzioni di riutilizzo del socket e le regole della piattaforma decidono l’esito esatto, ed è per questo che deve essere un’osservazione e non una regola da applicare a ogni distribuzione.

Trovate quale processo lo possiede

Gli endpoint numerici più le informazioni sul processo identificano il proprietario quando i vostri privilegi lo consentono, e il proprietario è ciò che vi serve, non il nome del programma. Due processi OpenVPN possono eseguire profili diversi, e quello che tiene il listener può essere il meno sospettato.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Confrontate ciò che trovate con il gestore dei servizi, un runtime di container o un processo di terminale rimasto da un test precedente. L’assenza di dettagli sul processo non è prova che il socket sia senza proprietario; di solito significa che la query è stata eseguita senza permessi sufficienti. Allo stesso modo, un elenco solo TCP non elimina un conflitto UDP, quindi ispezionate il trasporto indicato nell’errore. Il solo nome del processo non dice mai quale profilo è stato caricato, e il profilo è ciò che decide l’endpoint.

Un proprietario, o due istanze progettate

Se la distribuzione prevede un solo server, mantenete un solo proprietario del ciclo di vita e leggete il journal di quell’istanza o il log configurato invece di avviare una seconda copia per osservarla. Quando un’esecuzione controllata in primo piano è davvero necessaria, fermate deliberatamente l’istanza gestita e considerate i client che sta servendo prima di farlo.

Se sono previste due istanze, date loro listener distinti e distinto tutto il resto: pool di indirizzi, interfacce virtuali, politica di instradamento e proprietà della configurazione. Una porta diversa da sola non separa nulla oltre al socket, e i due server continueranno a contendersi lo stesso pool e le stesse rotte.

Tre scorciatoie meritano di essere nominate perché compaiono in ogni discussione su questo errore. Non uccidete un PID arbitrario che sembra il colpevole. Non attivate la condivisione del socket per zittire il messaggio. Non spostate un profilo server su una configurazione non associata in stile client perché questo fa sparire l’errore di binding; il server diventa irraggiungibile in un modo più difficile da diagnosticare del conflitto originale.

Cambiare porta è una risposta legittima solo quando il nuovo listener fa parte di un progetto approvato, che include la regola di inoltro e l’endpoint del client. Se questi non sono stati aggiornati, avete spostato il conflitto dove nessuno può trovarlo.

Verificate il binding prima di tutto il resto

Dopo la correzione circoscritta, confermate che l’istanza prevista è attiva, che il suo listener appare sul trasporto atteso e che un client può connettersi. Un binding riuscito completa solo la fase del socket locale; non certifica nulla sull’autenticazione né sul traffico una volta alzato il tunnel.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Se il socket è presente e il client continua a fallire, il problema rimanente è a valle e l’errore di binding è ormai storia. Quella separazione è tutto il senso del leggere prima il messaggio esatto: un errore, uno strato, un proprietario. Leggetelo così e il sintomo successivo partirà da uno stato noto invece che da un’ipotesi.