Nawala ng Access Server ang binding nito matapos palitan ang pangalan ng network interface: ayusin ang mga key

Pinalitan mo ng pangalan ang isang network interface, o nagbalik ka ng isang makina na ang adapter ay bumalik sa ibang pangalan, at ngayon hindi na nagsisimula ang daemon ng OpenVPN Access Server. Maaaring sumagot pa ang web interface o hindi, depende sa kung aling bahagi ang nakatali sa lumang pangalan. Hindi sira ang serbisyo at hindi nawala ang configuration; may isang setting na tumuturo pa rin sa isang interface na wala na ang host.

Ang karaniwang reaksyon ay i-install muli, simulan muli, o i-edit ang database hanggang mawala ang error. Ang bawat isa ay mas malaking pagbabago kaysa sa sira, at ang huli ay maaaring magbura ng mga user, pahintulot at dependency na nagpahalaga sa server na iligtas. Ito ay problema sa binding, at mayroon itong pinangalanang pag-aayos.

Ano ang talagang sinasabi ng sintomas

Ang daemon na hindi makapag-bind ay karaniwang nagsasabi nito sa sarili nitong log: hindi available ang address o wala ang interface. Ang mensahe ay tiyak: pinangalanan nito ang address na sinubukan ng daemon; ihambing ito sa ip -br addr sa host upang malaman kung ang interface ay pinalitan ng pangalan, tinanggal, o itinaas nang wala ang lumang address.

Panatilihing bukas ang isang awtorisadong recovery console sa buong oras. Kung ang binding na babaguhin mo ay nagdadala ng iyong nag-iisang administratibong session, pinutol mo ang iyong daan pabalik. Ang lokal na console, pangalawang address ng pamamahala, o dokumentadong out-of-band na landas ay ginagawang maibabalik ang pagbabago.

Tanungin ang configuration bago ito i-edit

Inilalantad ng Access Server ang configuration nito sa pamamagitan ng sarili nitong CLI. Ang dokumentadong view ay:

sacli ConfigQuery

Patakbuhin ito sa administratibong environment na dokumentado para sa iyong bersyon, hindi mula sa isang walang kaugnayang shell sa ibang host. I-save ang mga kasalukuyang value sa protektadong lugar bago magbago ng anuman, at huwag i-paste ang buong output sa pampublikong support thread.

Ang output na iyon ay view ng configuration ng server, hindi kumpletong backup. Hiwalay na tinatanong ang mga property ng user at group, kaya ang malinis na binding ay hindi nagbabalik ng mga pagkakakilanlan, at ang naibalik na pagkakakilanlan ay hindi nag-aayos ng listener. Itala ang dalawa bilang dalawang hiwalay na dokumento.

Tukuyin kung aling listener ang sira

Nagpapatakbo ang Access Server ng higit sa isang listener. Ang mga daemon ng OpenVPN ay nagdadala ng trapiko ng tunnel, ang web service ay nagdadala ng portal ng admin at kliyente, at ang ibang bahagi ay maaaring may sariling port. Ang nabigong kahilingan ng browser ay hindi nagsasabi kung alin ang nabigo, at ganoon din ang port number sa mensahe ng error.

Ang mga key ng binding ng daemon ay dokumentado bawat daemon, at sa opisyal na tutorial ang value ay ang identifier ng interface kahit nagtatapos sa ip_address ang mga pangalan ng key. Basahin ang pangungusap na iyon nang dalawang beses. Inaasahan din ng tutorial na magbabahagi ang mga daemon ng UDP at TCP ng isang interface, kaya ang pag-aayos ng isang key lamang ay bahagyang pag-aayos.

Baguhin ang pinangalanang setting, hindi ang mga tugmang row

Dokumentado ng tutorial ang ConfigPut sa mga partikular na key, tulad ng vpn.daemon.0.server.ip_address at vpn.daemon.0.listen.ip_address. Gamitin ang sariling paraan ng produkto kasama ang pangalan ng key at ang bagong value, sa syntax na dokumentado para sa iyong bersyon, at baguhin lamang ang mga key ng listener na na-diagnose mo.

Ang hindi mo dapat gawin ay hanapin sa database ang bawat row na ang value ay katumbas ng lumang pangalan ng interface at palitan silang lahat. Ipinapalagay nito na ang lumang pangalan ay lumitaw lamang sa mga setting ng listener, na hindi ipinangangako ng schema. Ginagawa rin nitong imposibleng suriin ang pagbabago.

Dalawang tukso pa ang dapat tanggihan. Ang pagbabalik ng default na nakikinig sa lahat ng interface ay desisyon sa pagka-expose, hindi pagwawasto ng baybay; ang inilaan na lokal na binding, ang nailathalang landas at ang pag-filter sa harap nito ay dapat sumang-ayon sa pagpiling iyon. Ang muling pagsisimula ng configuration ay nagpapalit ng pangalan ng problema sa halip na lutasin ito, dahil itinatapon ng bagong install ang mismong mga user at pahintulot na gumagana bago ang pagpapalit ng pangalan.

Ilapat ito, pagkatapos ay patunayang gumagana ang landas

Matapos maayos ang value, ilapat ito sa pamamagitan ng dokumentadong lifecycle ng produkto ( lifecycle ). Gumagamit ang tutorial ng sacli start matapos itakda ang mga key; hindi iyon buong reboot ng host o reset ng database.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Suriin ang listener, pagkatapos ay gumawa ng isang awtorisadong koneksyon ng VPN, maabot ang isang pribadong resource, at buksan ang administratibong pahina sa inaasahang landas nito. Panatilihin ang umiiral na mga pahintulot at pagbawi ng user; ang recovery na nag-reset sa mga ito ay naayos ang binding at nawala ang deployment. Tapos ang trabaho kapag gumagana ang parehong serbisyo sa inilaan nitong interface.