Pordo 1194 jam estas uzata: kiu posedas tiun OpenVPN-ingon?

Startigu la saman servilprofilon dufoje, kaj la dua procezo eliras kun eraro, ke la adreso jam estas uzata por pordo 1194. En la kutima kazo la diagnoza lanĉo kreis la konflikton, kaj la originala instanco ankoraŭ tute bone servas klientojn. Tiu rakonto klarigas grandan parton de tiuj ĉi raportoj, kaj indas rekoni ĝin antaŭ ol io ajn estos restartigita. Ĝi ankaŭ estas la plej malmultekosta versio por solvi.

La eraro priskribas lokan ligon kaj nenion preter ĝi. Ĝi ne estas pruvo, ke provizanto blokas la pordon, ke kliento sendis malĝustan pasvorton, aŭ ke la atestila ĉeno estas rompita.

Legu la precizan ligo-eraron

Du eraroj en tiu ĉi familio signifas malsamajn aferojn, kaj ilin miksi sendas vin al la malĝusta tavolo. „Adreso jam uzata“ diras, ke alia ingo tenas la finpunkton, kiun vi petis. „Adreso ne disponebla“ diras, ke la adreso, kiun vi petis, ankoraŭ ne ekzistas sur tiu ĉi gastiganto, kio estas preteca problemo, ne duplikato.

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

Kopiu la erartekston antaŭ ol ŝanĝi ion ajn, inkluzive de la adreso kaj pordo, kiujn ĝi nomas. Servo, kiu atendas aperon de interfaco, registros la duan eraron ripete kaj poste sukcese ligiĝos, kiam la adreso ekzistos; servo, kiu registras la unuan eraron, neniam sukcesos ĝis la duplikato estos solvita. Noti, kiun el la du vi vidis, kostas nenion kaj ŝparas vanan interfacan serĉadon.

Inventaru la ingon, ne la pordon

Pordnumero estas nekompleta inventaro. La finpunkto estas transporto, adresfamilio, loka adreso kaj pordo, ĉio ene de unu reta nomspaco. UDP-aŭskultanto kaj TCP-aŭskultanto sur la sama numero estas malsamaj ingoj, kaj du procezoj sur la sama numero en malsamaj nomspacoj neniam renkontiĝas.

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

Unue rulu la transporton, kiun la profilo efektive uzas. Poste rigardu la kolumnon de la loka adreso anstataŭ nur la numeron: ĵokera ligo kovras ĉiun lokan adreson, do dua procezo petanta unu specifan adreson povas kolizii kun ĝi, eĉ se la presitaj signoĉenoj malsamas. Opcioj de inga reuzo kaj platformaj reguloj decidas la precizan rezulton, tial ĉi tio devus esti observado, ne regulo, kiun vi aplikas al ĉiu deplojo.

Trovu, kiu procezo posedas ĝin

Numeraj finpunktoj plus procezaj informoj identigas la posedanton, kiam viaj privilegioj permesas tion, kaj la posedanto estas tio, kion vi bezonas, ne la programnomo. Du OpenVPN-procezoj povas ruli malsamajn profilojn, kaj tiu, kiu tenas la aŭskultanton, povas esti la malplej atendata.

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

Komparu tion, kion vi trovas, kun la servoadministranto, ujuja rultempo aŭ terminala procezo restinta de pli frua testo. Manko de procezaj detaloj ne estas pruvo, ke la ingo estas senposeda; ĝi kutime signifas, ke la demando kuris sen sufiĉa permeso. Same, listo nur TCP ne nuligas UDP-konflikton, do inspektu la transporton nomitan en la eraro. Nur proceza nomo neniam diras, kiu profilo estis ŝargita, kaj la profilo estas tio, kio decidas la finpunkton.

Unu posedanto, aŭ du planitaj instancoj

Se la deplojo celas unu servilon, tenu unu posedanton de la vivociklo kaj legu la ĵurnalon de tiu instanco aŭ la agorditan protokolon anstataŭ lanĉi duan kopion por observi ĝin. Kiam kontrolita antaŭplana rulado estas vere necesa, haltigu la administritan instancon konscie kaj antaŭe konsideru la klientojn, kiujn ĝi servas.

Se du instancoj estas celitaj, donu al ili apartajn aŭskultantojn kaj apartan ĉion alian: adresarojn, virtualajn interfacojn, enkursigan politikon kaj agordan posedon. Nur malsama pordo apartigas nenion krom la ingo, kaj la du serviloj daŭre batalos pri la sama adresaro kaj la samaj enkursigoj.

Tri fuĝvojoj indas esti nomitaj, ĉar ili aperas en ĉiu fadeno pri tiu ĉi eraro. Ne mortigu arbitran PID-on, kiu aspektas kiel la kulpulo. Ne ŝaltu ingan kunuzadon por silentigi la mesaĝon. Ne ŝanĝu servilan profilon al klientstila neligita agordo, ĉar tio igas la ligo-eraron malaperi; la servilo fariĝas neatingebla tiel, ke estas pli malfacile diagnozi ol la origina konflikto.

Ŝanĝi la pordon estas legitima respondo nur kiam la nova aŭskultanto estas parto de aprobita dezajno, kiu inkluzivas la plusendan regulon kaj la klientan finpunkton. Se tiuj ne estis ĝisdatigitaj, vi movis la konflikton al loko, kie neniu povas trovi ĝin.

Kontrolu la ligon antaŭ io ajn alia

Post la limigita korekto, konfirmu, ke la celita instanco estas aktiva, ke ĝia aŭskultanto aperas sur la transporto, kiun vi atendas, kaj ke kliento povas konektiĝi. Sukcesa ligo nur kompletigas la lokan ingan stadion; ĝi atestas nenion pri aŭtentikigo aŭ pri trafiko post kiam la tunelo staras.

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

Se la ingo ĉeestas kaj la kliento ankoraŭ malsukcesas, la restanta problemo estas malsupre kaj la ligo-eraro jam estas historio. Tiu apartigo estas la tuta senco de unue legi la precizan mesaĝon: unu eraro, unu tavolo, unu posedanto. Legu ĝin tiel, kaj la sekva simptomo komenciĝos de konata stato anstataŭ de konjekto.