Port 1194 er allereie i bruk: kven eig den OpenVPN-sokkelen?

Start same tenarprofil to gonger, og den andre prosessen avsluttar med ein feil om at adressa allereie er i bruk for port 1194. I det vanlege tilfellet skapte den diagnostiske oppstarten konflikten, og den opphavlege instansen tenar framleis klientane heilt fint. Denne historia forklarer ein stor del av desse rapportane, og det er verdt å kjenne henne att før noko blir starta på nytt. Det er òg den billegaste versjonen å løyse.

Feilen skildrar ei lokal binding og ingenting utover det. Det er ikkje prov på at ein leverandør blokkerer porten, at ein klient sende feil passord, eller at sertifikatkjeda er broten.

Les den nøyaktige bindingsfeilen

To feil i denne familien tyder ulike ting, og å blande dei saman sender deg til feil lag. «Adressa er allereie i bruk» seier at ein annan sokk held endepunktet du bad om. «Adressa er ikkje tilgjengeleg» seier at adressa du bad om enno ikkje finst på denne verten, noko som er eit beredskapsproblem og ikkje ein duplikat.

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

Kopier feilteksten før du endrar noko, inkludert adressa og porten han nemner. Ein teneste som ventar på at eit grensesnitt skal dukke opp, vil logge den andre feilen gong på gong og deretter binde vellukka når adressa finst; ein teneste som loggar den første feilen, vil aldri lukkast før duplikatet er løyst. Å notere kva av dei du såg, kostar ingenting og sparar ei bortkasta grensesnittjakt.

Inventer sokkelen, ikkje porten

Eit portnummer er ei ufullstendig oversikt. Endepunktet er ein transport, ein adressefamilie, ei lokal adresse og ein port, alt innanfor eitt enkelt nettverksnamnerom. Ein UDP-lyttar og ein TCP-lyttar på same nummer er ulike sokklar, og to prosessar på same nummer i ulike namnerom møtest aldri.

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

Køyr først transporten som profilen faktisk brukar. Sjå deretter på kolonnen for den lokale adressa i staden for berre nummeret: ei jokerteiknbinding dekkjer alle lokale adresser, så ein annan prosess som ber om éi bestemd adresse kan kollidere med henne sjølv om dei utskrivne strengane er ulike. Alternativ for gjenbruk av sokk og plattformreglar avgjer det nøyaktige resultatet, og difor bør dette vere ei observasjon og ikkje ein regel du brukar på kvar utrulling.

Finn ut kva prosess som eig han

Numeriske endepunkt pluss prosessinformasjon identifiserer eigaren når rettane dine tillèt det, og eigaren er det du treng, ikkje programnamnet. To OpenVPN-prosessar kan køyre ulike profilar, og den som held lyttaren, kan vere den du minst ventar.

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

Samanlikn det du finn med tenesteadministratoren, eit container-runtime eller ein terminalprosess som er til overs frå ein tidlegare test. Fråvær av prosessdetaljar er ikkje prov på at sokkelen er utan eigar; det tyder vanlegvis at spørjinga køyrde utan tilstrekkeleg løyve. På same måte opphevar ikkje ei liste med berre TCP ein UDP-konflikt, så undersøk transporten som er nemnd i feilen. Eit prosessnamn åleine fortel aldri kva profil som vart lasta, og profilen er det som avgjer endepunktet.

Éin eigar, eller to designa instansar

Viss utrullinga siktar på éin tenar, hald éin livssykluseigar og les journalen til den instansen eller den konfigurerte loggen i staden for å starte ein andre kopi for å overvake han. Når ei kontrollert køyring i forgrunnen verkeleg er naudsynt, stopp den administrerte instansen medvite og ta omsyn til klientane han tenar før du gjer det.

Viss to instansar er meint, gje dei ulike lyttarar og ulikt alt anna: adressebasseng, virtuelle grensesnitt, rutingspolitikk og konfigurasjonseigarskap. Ein annan port åleine skil ingenting anna enn sokkelen, og dei to tenarane vil framleis kjempe om same basseng og same ruter.

Tre snarvegar er verdt å nemne fordi dei dukkar opp i kvar tråd om denne feilen. Ikkje drep ein vilkårleg PID som ser ut som syndaren. Ikkje aktiver sokkeldeling for å bringe meldinga til tagnad. Ikkje byt ein tenarprofil til ein klientliknande ubunden konfigurasjon fordi det får bindingsfeilen til å forsvinne; tenaren blir utilgjengeleg på ein måte som er vanskelegare å diagnostisere enn den opphavlege konflikten.

Å endre porten er berre eit legitimt svar når den nye lyttaren er ein del av eit godkjent design, som inkluderer vidaresendingsregelen og endepunktet til klienten. Viss desse ikkje vart oppdaterte, har du flytta konflikten til ein stad der ingen kan finne han.

Stadfest bindinga før alt anna

Etter den avgrensa rettinga, stadfest at den tiltenkte instansen er aktiv, at lyttaren hans viser seg på transporten du ventar, og at ein klient kan kople til. Ei vellukka binding fullfører berre den lokale sokkefasen; ho stadfestar ingenting om autentisering eller om trafikk etter at tunnelen er oppe.

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

Viss sokkelen er til stades og klienten framleis feilar, er det gjenverande problemet nedstraums og bindingsfeilen er no historie. Denne separasjonen er heile poenget med å lese den nøyaktige meldinga først: éin feil, eitt lag, éin eigar. Les det slik, og neste symptom startar frå ein kjend tilstand i staden for frå ei gjetting.