Poarte 1194 is al yn gebrûk: wa besit dy OpenVPN-socket?

Start itselde tsjinnerprofyl twa kear en it twadde proses einiget mei in flater dat it adres al yn gebrûk is foar poarte 1194. Yn it gewoane gefal hat de diagnostyske start it konflikt makke, en de oarspronklike ynstânsje tsjinnet de kliïnten noch hielendal goed. Dat ferhaal ferklearret in grut part fan dizze rapporten, en it is de muoite wurdich om it te werkenne foardat der eat opnij start wurdt. It is ek de goedkeapste ferzje om op te lossen.

De flater beskriuwt in pleatslike bining en neat dêrbûten. It is gjin bewiis dat in oanbieder de poarte blokkearret, dat in kliïnt it ferkearde wachtwurd stjoerd hat, of dat de sertifikaatkeatling brutsen is.

Lês de krekte binningsflater

Twa flaters yn dizze famylje betsjutte ferskillende dingen, en se trochinoar helje stjoert jo nei de ferkearde laach. „Adres al yn gebrûk“ seit dat in oare socket it einpunt hâldt dat jo oanfrege hawwe. „Adres net beskikber“ seit dat it adres dat jo oanfrege hawwe noch net op dizze host bestiet, wat in probleem fan reeheid is en net in duplikaat.

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

Kopiearje de flatertekst foardat jo eat feroarje, ynklusyf it adres en de poarte dy’t it neamt. In tsjinst dy’t wachtet oant in ynterface ferskynt, sil de twadde flater hieltyd wer logge en dan suksesfol binde sadree’t it adres bestiet; in tsjinst dy’t de earste flater logt, sil nea slagje oant it duplikaat oplost is. Notearje hokker fan de twa jo seagen kostet neat en sparret in fergriemde ynterface-sykltocht.

Yngrommelje de socket, net de poarte

In poartenûmer is in ûnfolsleine ynventarisaasje. It einpunt is in ferfier, in adresfamylje, in pleatslik adres en in poarte, alles binnen ien netwurknammeromte. In UDP-harker en in TCP-harker op itselde nûmer binne ferskillende sockets, en twa prosessen op itselde nûmer yn ferskillende nammeromten treffe inoar nea.

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

Rin earst it ferfier dat it profyl eins brûkt. Sjoch dan nei de kolom fan it pleatslike adres yn stee fan allinnich it nûmer: in wildcard-bining omfettet elk pleatslik adres, sadat in twadde proses dat ien spesifyk adres freget der botse kin, sels as de printe strings ferskille. Socket-werbrûkopjes en platfoarmregels beslisse de krekte útkomst, dêrom moat dit in observaasje wêze en net in regel dy’t jo op elke útrôling tapasse.

Sykje út hokker proses it besit

Numerike einpunten plus prosesynformaasje identifisearje de eigner as jo foarrjochten it tastean, en de eigner is wat jo nedich hawwe, net de programnamme. Twa OpenVPN-prosessen kinne ferskillende profylen rinne litte, en dejinge dy’t de harker hâldt, kin dejinge wêze dy’t jo it minst ferwachtsje.

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

Ferlykje wat jo fine mei de tsjinstbehearder, in container-runtime of in terminalproses dat fan in eardere test oerbleaun is. It ûntbrekken fan prosesdetails is gjin bewiis dat de socket gjin eigner hat; it betsjut meast dat de fraach sûnder genôch tastimming rûn. Likegoed heftet in list mei allinnich TCP in UDP-konflikt net op, dus ûndersykje it ferfier dat yn ’e flater neamd wurdt. In prosesnamme allinnich fertelt nea hokker profyl laden is, en it profyl is wat it einpunt beslisset.

Ien eigner, of twa ûntwurpen ynstânsjes

As de útrôling ien tsjinner bedoelt, hâld dan ien libbenssykluseigner en lês it sjoernaal fan dy ynstânsje of it konfigurearre log yn stee fan in twadde kopy te starten om dy te besjen. As in kontrolearre foargrûnrinnen wier needsaaklik is, stopje dan de behearde ynstânsje bewust en hâld rekken mei de kliïnten dy’t it tsjinnet foardat jo dat dogge.

As twa ynstânsjes bedoeld binne, jou harren ferskillende harkers en ferskillend al it oare: adrespools, firtuele ynterfaces, routingbelied en konfiguraasje-eignerskip. In oare poarte allinnich skiedt neat oars as de socket, en de twa tsjinners fjochtsje noch altyd om deselde pool en deselde rûtes.

Trije koarten binne it neamen wurdich, want se ferskine yn elke thread oer dizze flater. Deadzje gjin willekeurige PID dy’t op de skuldige liket. Skeakelje gjin socket-dielen yn om it berjocht stil te meitsjen. Skeakelje in tsjinnerprofyl net oer nei in kliïnt-eftige losse konfiguraasje, want dan ferdwynt de binningsflater; de tsjinner wurdt dan net berikber op in manier dy’t hurder te diagnostisearjen is as it oarspronklike konflikt.

De poarte feroarje is allinnich in legitime antwurd as de nije harker diel is fan in goedkarde ûntwerp, dat de trochstjoerregel en it kliïnteinpunt omfettet. As dy net bywurke binne, hawwe jo it konflikt ferpleatst nei in plak dêr’t nimmen it fine kin.

Ferifiearje de bining foar al it oare

Nei de beheinde korreksje, befestigje dat de bedoelde ynstânsje aktyf is, dat de harker ferskynt op it ferfier dat jo ferwachtsje, en dat in kliïnt ferbine kin. In suksesfolle bining foltôget allinnich de pleatslike socket-fase; it sertifisearret neat oer autentikaasje of oer ferkear nei’t de tunnel stiet.

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

As de socket oanwêzich is en de kliïnt noch altyd mislearret, is it oerbleaune probleem stroomôf en is de binningsflater no skiednis. Dy skieding is it hiele punt fan it earst lêzen fan it krekte berjocht: ien flater, ien laach, ien eigner. Lês it sa, en it folgjende symptoom begjint by in bekende tastân yn stee fan by in gissing.