Ginagamit na ang port 1194: kanino ang OpenVPN socket na iyon?

Simulan ang parehong profile ng server nang dalawang beses, at ang ikalawang proseso ay lumalabas na may error na ginagamit na ang address para sa port 1194. Sa karaniwang kaso, ang diagnostic launch ang lumikha ng salungatan, at ang orihinal na instance ay naglilingkod pa rin sa mga kliyente nang maayos. Ipinapaliwanag ng kuwentong ito ang malaking bahagi ng mga ulat na ito, at sulit itong kilalanin bago i-restart ang anuman. Ito rin ang pinakamurang bersyon na malulutas.

Inilalarawan ng error ang isang lokal na binding at wala nang iba pa. Hindi ito patunay na hinaharangan ng provider ang port, na nagpadala ang kliyente ng maling password, o na sira ang certificate chain.

Basahin ang eksaktong binding error

Dalawang error sa pamilyang ito ang may magkaibang kahulugan, at ang paghahalo sa kanila ay magdadala sa iyo sa maling layer. Ang «ginagamit na ang address» ay nagsasabing may ibang socket na humahawak sa endpoint na hiniling mo. Ang «hindi available ang address» ay nagsasabing wala pa ang address na hiniling mo sa host na ito, na problema sa pagiging handa at hindi duplicate.

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

Kopyahin ang teksto ng error bago baguhin ang anuman, kasama ang address at port na binabanggit nito. Ang serbisyong naghihintay na lumitaw ang interface ay paulit-ulit na itatala ang ikalawang error at pagkatapos ay matagumpay na magbi-bind kapag umiral ang address; ang serbisyong nagtatala ng unang error ay hindi kailanman magtatagumpay hangga't hindi nalulutas ang duplicate. Ang pagtala kung alin sa dalawa ang nakita mo ay walang gastos at nakakatipid ng nasayang na paghahanap ng interface.

I-inventory ang socket, hindi ang port

Ang numero ng port ay isang hindi kumpletong imbentaryo. Ang endpoint ay isang transport, isang pamilya ng address, isang lokal na address at isang port, lahat sa loob ng isang namespace ng network. Ang listener ng UDP at listener ng TCP sa parehong numero ay magkaibang socket, at dalawang proseso sa parehong numero sa magkaibang namespace ay hindi kailanman nagtatagpo.

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

Patakbuhin muna ang transport na aktuwal na ginagamit ng profile. Pagkatapos ay tingnan ang kolum ng lokal na address at hindi lamang ang numero: ang wildcard binding ay sumasakop sa bawat lokal na address, kaya ang ikalawang proseso na humihingi ng isang partikular na address ay maaaring mabangga ito kahit magkaiba ang mga nakalimbag na string. Ang mga opsyon sa muling paggamit ng socket at mga tuntunin ng platform ang nagpapasya sa eksaktong resulta, kaya dapat itong maging obserbasyon at hindi tuntuning inilalapat mo sa bawat deployment.

Alamin kung aling proseso ang may-ari nito

Ang mga numerikong endpoint at impormasyon ng proseso ay tumutukoy sa may-ari kapag pinahihintulutan ng iyong mga pribilehiyo, at ang may-ari ang kailangan mo, hindi ang pangalan ng programa. Dalawang proseso ng OpenVPN ang maaaring magpatakbo ng magkaibang profile, at ang may hawak ng listener ay maaaring ang hindi mo inaasahan.

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

Ihambing ang makikita mo sa service manager, isang container runtime o isang terminal process na natira mula sa naunang pagsubok. Ang kawalan ng detalye ng proseso ay hindi patunay na walang may-ari ang socket; karaniwang ibig sabihin nito ay tumakbo ang query nang walang sapat na pahintulot. Gayundin, ang listahang TCP lamang ay hindi nag-aalis ng salungatan sa UDP, kaya siyasatin ang transport na binanggit sa error. Ang pangalan ng proseso lamang ay hindi kailanman nagsasabi kung aling profile ang na-load, at ang profile ang nagpapasya sa endpoint.

Isang may-ari, o dalawang dinisenyong instance

Kung ang deployment ay para sa isang server, panatilihin ang isang may-ari ng lifecycle at basahin ang journal ng instance na iyon o ang naka-configure na log sa halip na maglunsad ng pangalawang kopya para obserbahan ito. Kapag tunay na kailangan ang kontroladong pagpapatakbo sa foreground, sadyang ihinto ang pinamamahalaang instance at isaalang-alang ang mga kliyenteng pinaglilingkuran nito bago gawin iyon.

Kung dalawang instance ang nilalayon, bigyan sila ng magkaibang listener at magkaiba ang lahat ng iba pa: mga pool ng address, virtual interface, patakaran sa routing at pagmamay-ari ng configuration. Ang magkaibang port lamang ay walang ibinubukod maliban sa socket, at ang dalawang server ay magpapatuloy pa rin sa pag-aagawan sa parehong pool at parehong ruta.

Tatlong shortcut ang dapat banggitin dahil lumilitaw ang mga ito sa bawat usapan tungkol sa error na ito. Huwag patayin ang anumang PID na mukhang salarin. Huwag paganahin ang pagbabahagi ng socket para patahimikin ang mensahe. Huwag ilipat ang profile ng server sa isang hindi naka-bind na configuration na parang kliyente dahil pinapawi nito ang binding error; nagiging hindi maabot ang server sa paraang mas mahirap i-diagnose kaysa sa orihinal na salungatan.

Ang pagpalit ng port ay lehitimong sagot lamang kapag ang bagong listener ay bahagi ng isang aprubadong disenyo, na kasama ang patakaran sa pagpapasa at ang endpoint ng kliyente. Kung hindi na-update ang mga iyon, inilipat mo ang salungatan sa lugar na walang makakahanap.

I-verify ang binding bago ang lahat ng iba pa

Pagkatapos ng limitadong pagwawasto, kumpirmahin na aktibo ang nilalayong instance, lumilitaw ang listener nito sa transport na inaasahan mo, at makakakonekta ang isang kliyente. Ang matagumpay na binding ay kumukumpleto lamang sa yugto ng lokal na socket; wala itong pinapatunayan tungkol sa authentication o sa trapiko kapag nakaangat na ang tunnel.

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

Kung naroon ang socket at nabibigo pa rin ang kliyente, ang natitirang problema ay nasa ibaba at ang binding error ay kasaysayan na. Ang paghihiwalay na iyon ang buong punto ng pagbasa muna ng eksaktong mensahe: isang error, isang layer, isang may-ari. Basahin ito nang ganoon at ang susunod na sintomas ay magsisimula sa kilalang estado at hindi sa haka-haka.