Nabigo ang lokal na bind ng OpenVPN sa boot: maghintay o mag-ulit

Para sa isang OpenVPN server na hindi nagsisimula sa boot, may dalawang solusyong iniaalok: hintayin ang address, o hayaang ulitin ng serbisyo hanggang maging matagumpay ang bind. Pareho silang tumutugon sa iisang sintomas ngunit magkaiba ang ugali kapag nabigo. Ang paghihintay ay naglalakip ng tiyak na paunang kundisyon at malakas na nabigo kapag wala ito; ang pag-uulit ay nagtatago ng paunang kundisyon at patuloy na sumusubok. Kung alin sa dalawa ang nababagay sa iyong unit ay depende sa kung ang address ay sinadyang dependency o aksidente lamang ng tiyempo.

Mas mabuti ang dalawa kaysa sa isang fixed sleep, na walang hinihintay at walang iniuulat kung ano ang hinintay nito.

Ano ba talaga ang kailangan ng opsyong local

local ang nagsasaad ng address na kinabibitbit ng daemon sa socket nito, at ang pagbind sa isang address na wala pa ay agad na nabigo na may error tungkol sa hiniling na address. Kapag wala ang opsyong ito, nakikinig ang daemon sa lahat ng address, kaya gumagana ang parehong profile sa makina na hindi pa nakabangon ang interface: nakikinig ito sa lahat ng dako sa halip na sa iisang address na pinangalanan mo. Ang pagkakaibang iyon ang bumubuo sa buong pagkabigo, at nananatili itong di-nakikita hanggang sa isang reboot.

Ang kailangan ay hindi ang basta pagbangon ng interface sa pangkalahatang diwa. Dapat nakatalaga ang address sa tamang interface sa mismong sandali ng bind, at dapat ito ang pinagbabatayang interface at hindi isang tunnel na gagawin ng parehong daemon mamaya. Ang pagsusuring ginawa ilang minuto pagkatapos mag-login ay walang pinapatunayan tungkol sa pagkakasunod-sunod ng boot.

Paghihintay sa address kumpara sa pag-uulit ng bind

Ang paghihintay ay isang ExecStartPre na paulit-ulit na nagtatanong hanggang lumitaw ang address, may limitadong bilang ng pagtatangka at di-sero na exit kapag naubos ang oras. Ang pag-uulit ay pagpayag na mabigo ang pangunahing proseso at paghiling sa tagapamahala ng serbisyo na simulan itong muli, halimbawa Restart=on-failure kasama ng RestartSec=5. Iniuulat ng una ang kulang na paunang kundisyon bilang bigong unit, samantalang iniuulat ito ng pangalawa bilang sunod na mga restart na sa huli ay tumitigil; mas maingay ito sa journal ngunit nakakayanan ang address na huling dumating dahil sa mga dahilang hindi mo mahulaan.

Mas piliin ang paghihintay kapag ang address ay sinadyang dependency, at piliin ang pag-uulit kapag karaniwang lumilitaw ang address ngunit nagbabago ang tiyempo. Makatuwiran ang pagsasama ng dalawa: sinasaklaw ng may hanggang paghihintay ang karaniwang kaso at sinasaklaw ng patakaran ng restart ang eksepsyon. Ang hindi dapat gawin ng alinman ay tumakbo nang walang hanggan, dahil ang unit na walang tigil na umuulit ay nagtatago ng maling konfigurasyon sa halip na iulat ito.

Bakit hindi sapat ang network-online.target

network-online.target ay nangangako lamang ng anumang ibig sabihin ng online sa aktibong implementasyon ng network, at wala nang iba. Sa systemd-networkd, ang systemd-networkd-wait-online ang nagpapasya kung kailan naabot ang target na iyon, at ang default nitong pag-unawa sa online ay maaaring matugunan bago pa umiral ang iyong partikular na address. Sa ilalim ng NetworkManager, inilalapat ng serbisyong wait-online ang sarili nitong mga alituntunin. Ang pagsunod pagkatapos ng target ay matatag na batayan, hindi garantiya na handa na ang isang address, sagot ng DNS o malayong peer.

Ang parehong pangangatwiran ay nag-aalis sa mga karaniwang alternatibo. Ang autostart entry sa desktop ay naghihintay ng sesyon ng user na maaaring hindi kailanman bumukas sa isang server, at ang naantalang utos ng cron ay nagdaragdag ng lumipas na oras nang hindi pinapangalanan ang resource na inasahan nitong lilitaw. Pareho silang maaaring magmukhang matagumpay nang ilang buwan at pagkatapos ay mabigo sa nag-iisang boot na mahalaga.

Suriin ang bind pagkatapos ng cold boot

Patunayan sa tunay na cold boot, hindi sa restart ng serbisyo, dahil ang restart ay nagmamana ng address na kinailangang likhain ng pagkakasunod-sunod ng boot. Pagkatapos ng boot, ipinapakita ng ss -lntp o ss -lunp ang lokal na address na aktwal na kinabitan ng bawat listener, at ipinapakita ng journalctl -b -u openvpn-server@server kung nabigo ang unang pagtatangka. Ihambing ang nakabind na address sa nasa profile, pagkatapos ay ulitin ang paghahambing pagkatapos ng muling pagkonekta sa network.

Kung kailanman ay hindi nangailangan ang profile ng fixed address, ang pag-alis ng local ay lehitimong pagpapasimple, ngunit gawin itong desisyon sa seguridad at hindi ugali sa pag-troubleshoot.

Ang pagpapalawak ng listener ay nagbabago kung sino ang makakaabot dito, kaya isabay ang pagbabagong iyon sa patakaran ng firewall na dapat sana ay naglilimita dito. Ang serbisyong maaasahang nagsisimula sa bawat interface ay hindi pa nalutas ang orihinal na problema; inilipat lamang nito ang problema sa gilid ng network.