El port 1194 ja està en ús: qui posseeix aquest sòcol OpenVPN?

Inicieu el mateix perfil de servidor dues vegades i el segon procés surt amb un error d’adreça en ús per al port 1194. En el cas habitual, l’arrencada de diagnòstic va crear el conflicte i la instància original encara serveix els clients perfectament. Aquesta història explica una gran part d’aquests informes i val la pena reconèixer-la abans de reiniciar res. També és la versió més barata de resoldre.

L’error descriu un enllaç local i res més enllà. No és prova que un proveïdor bloqui el port, que un client hagi enviat la contrasenya incorrecta o que la cadena de certificats estigui trencada.

Llegiu l’error exacte d’enllaç

Dos errors d’aquesta família signifiquen coses diferents, i barrejar-los us porta a la capa equivocada. «Adreça ja en ús» diu que un altre sòcol té el punt final que heu demanat. «Adreça no disponible» diu que l’adreça que heu demanat encara no existeix en aquest amfitrió, cosa que és un problema de preparació, no un duplicat.

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

Copieu el text de l’error abans de canviar res, incloent-hi l’adreça i el port que esmenta. Un servei que espera que aparegui una interfície registrarà el segon error repetidament i després s’enllaçarà correctament quan l’adreça existeixi; un servei que registra el primer error no tindrà èxit mai fins que es resolgui el duplicat. Anotar quin dels dos heu vist no costa res i estalvia una cerca d’interfícies inútil.

Inventeu el sòcol, no el port

Un número de port és un inventari incomplet. El punt final és un transport, una família d’adreces, una adreça local i un port, tot dins d’un sol espai de noms de xarxa. Un oient UDP i un oient TCP sobre el mateix número són sòcols diferents, i dos processos sobre el mateix número en espais de noms diferents no es troben mai.

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

Executeu primer el transport que el perfil realment utilitza. Després mireu la columna de l’adreça local i no només el número: un enllaç comodí cobreix totes les adreces locals, així que un segon procés que demana una adreça concreta pot xocar-hi tot i que les cadenes impreses siguin diferents. Les opcions de reutilització de sòcols i les regles de la plataforma decideixen el resultat exacte, i per això això ha de ser una observació i no una regla que apliqueu a cada desplegament.

Trobeu quin procés el posseeix

Els punts finals numèrics més la informació del procés identifiquen el propietari quan els vostres privilegis ho permeten, i el propietari és el que necessiteu, no el nom del programa. Dos processos OpenVPN poden executar perfils diferents, i el que té l’oient pot ser el que menys sospiteu.

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

Compareu el que trobeu amb el gestor de serveis, un entorn d’execució de contenidors o un procés de terminal sobrant d’una prova anterior. L’absència de detalls del procés no és prova que el sòcol no tingui propietari; normalment vol dir que la consulta es va executar sense prou permís. Igualment, un llistat només TCP no descarta un conflicte UDP, així que inspeccioneu el transport esmentat a l’error. El nom del procés sol no diu mai quin perfil s’ha carregat, i el perfil és el que decideix el punt final.

Un propietari, o dues instàncies dissenyades

Si el desplegament vol un sol servidor, manteniu un sol propietari del cicle de vida i llegiu el registre d’aquesta instància o el log configurat en lloc d’engegar una segona còpia per observar-la. Quan una execució controlada en primer pla sigui realment necessària, atureu la instància gestionada deliberadament i tingueu en compte els clients que serveix abans de fer-ho.

Si es volen dues instàncies, doneu-los oients diferents i tot la resta diferent: pools d’adreces, interfícies virtuals, política d’encaminament i propietat de la configuració. Un port diferent sol no separa res més que el sòcol, i els dos servidors encara es barallaran pel mateix pool i les mateixes rutes.

Tres dreceres val la pena nomenar-les perquè apareixen a tots els fils sobre aquest error. No mateu un PID arbitrari que sembli el culpable. No activeu la compartició de sòcols per silenciar el missatge. No canvieu un perfil de servidor a una configuració no lligada d’estil client perquè això fa desaparèixer l’error d’enllaç; el servidor deixa de ser accessible d’una manera més difícil de diagnosticar que el conflicte original.

Canviar el port és una resposta legítima només quan el nou oient forma part d’un disseny aprovat, que inclou la regla de reenviament i el punt final del client. Si no s’han actualitzat, heu traslladat el conflicte a un lloc on ningú no el pot trobar.

Verifiqueu l’enllaç abans que res

Després de la correcció acotada, confirmeu que la instància prevista està activa, que el seu oient apareix al transport que espereu i que un client es pot connectar. Un enllaç correcte només completa l’etapa del sòcol local; no certifica res sobre l’autenticació ni sobre el trànsit un cop el túnel està aixecat.

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

Si el sòcol hi és i el client encara falla, el problema restant és aigües avall i l’error d’enllaç ja és història. Aquesta separació és tot el sentit de llegir primer el missatge exacte: un error, una capa, un propietari. Llegiu-ho així i el següent símptoma comença des d’un estat conegut i no des d’una suposició.