Ruta ng appliance na OpenVPN: may-ari ng config o startup script?
Ang rutang sangay na nakaligtas sa isang reboot ay maaari pa ring mawala pagkatapos ng pag-save sa GUI o pag-update ng firmware. Ihambing ang sinusuportahang may-ari ng config sa isang patch script.
Nagdadagdag ka ng rutang sangay, gumagana ito, at pagkatapos ay tinatanggal ito ng pag-update ng firmware o pag-save mula sa web UI. Dalawang pagwawasto ang mukhang parehong makatwiran sa sandaling iyon: ilagay ang ruta sa sinusuportahang pinagmulan ng config ng appliance, o idagdag ito sa nabuong file mula sa isang startup script. Pareho silang kumikilos sa loob ng isang linggo at naghihiwalay sa pangalawang upgrade. Inihahambing ng artikulong ito kung ano ang tunay na pag-aari ng bawat isa.
Magkaiba ang pag-aari ng dalawang kandidato
Ang sinusuportahang pinagmulan ng config ay lahat ng itinuturing ng appliance na input: field ng GUI, na-import na profile, dokumentadong direktoryo bawat kliyente, database ng mga setting na binabasa ng management package. Ang nabuong server.conf ay output. Gumagana ang pag-edit ng output hanggang sa muling tumakbo ang generator, at nangyayari iyon sa pag-save, sa reboot at sa pag-upgrade.
Pinapatch ng diskarteng may script ang output na iyon pagkatapos matapos ang generator. Lehitimong teknik ito para sa isang lab, at ito ang maling default para sa sangay na opisina, dahil ginagawa nitong nakadepende ang ruta sa pagtutugma ng teksto sa halip na sa dokumentadong field.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
Ano ang muling ginagawa ng appliance, at kailan
Karaniwang itinatago ng mga management package ang mga setting sa isang database o set ng template at ginagawa ang config ng daemon sa pagsisimula. Madalas na muling isinusulat ng pag-save mula sa web UI ang buong file sa halip na i-patch ang isang linya. Kung ang pagbabago mo ay nanirahan sa file na iyon, wala na ito ngayon, at walang naglo-log ng babala, dahil mula sa pananaw ng appliance walang nawala.
Ang mga start wrapper ay may pangalawang failure mode. Ang grep para sa direktiba na may partikular na espasyo ay humihinto sa pagtutugma pagkatapos ng pagbabago ng template, at tahimik na walang ginagawa ang script. Mas malala, maaaring palitan ng pag-update ng firmware ang wrapper ng bagong bersyon, dalhin ang patch. Pagkatapos mayroon kang rutang umiral nang isang taon at nawala sa panahon ng maintenance na walang nag-ugnay sa routing.
Ano ang dapat ipahayag ng sinusuportahang may-ari
Kailangan ng tatlong pahayag ang prefix ng sangay, hindi isa. Dapat matutunan ng kliyente ang ruta, dapat malaman ng server kung aling authenticated na kliyente ang may-ari ng prefix, at dapat ibalik ng panig ng sangay ang trapiko sa tunnel address na ibinigay dito. Sa mga termino ng OpenVPN nangangahulugan iyon ng isang naka-push na route, isang tumutugmang iroute na nakatali sa kliyente, at isang daan pabalik sa kabilang panig.
Dito nagmimislead ang mga UI ng appliance. Ang checkbox na may label na “payagan ang mga kliyente na ma-access ang LAN ng server” ay naglalarawan ng trapikong patungo sa sariling network ng server. Ang iyong sangay ay kabaligtaran ng direksyon: isang network sa likod ng isang kliyente, na maabot mula sa panig ng server. Ang parehong label ay hindi nagpapahiwatig ng suporta para doon, at ang wastong direktiba sa isang file ay hindi pangako na mapapanatili ito ng package.
Kapag walang sinusuportahang kontrol
Minsan ay talagang hindi maipahayag ng naka-install na release ang rutang partikular sa peer. Pagkatapos ang tapat na mga opsyon ay isa pang gateway na kinokontrol mo, o isang sinusuportahang site-to-site mode sa magkabilang dulo. Dapat itong sabihin ng magkabilang dulo. Ang pahina ng produkto na nagsasabing site-to-site ay hindi ginagawang mapagpapalit ang isang arbitrary na profile ng OpenVPN sa tunnel ng ibang protocol, at ang pagpilit sa pares na iyon ay karaniwang gumagawa ng kalahating-konektadong tunnel na mukhang maayos sa pahina ng status.
Piliin ang opsyon na maipaliwanag mo sa isang pangungusap sa sinumang magmamana ng network. Kung kailangang banggitin ng sagot ang isang landas ng script at pattern ng teksto, marupok na ang disenyo.
Gawing auditible ang layunin
Itala ang kontrata sa labas ng appliance: epektibong pagkakakilanlan ng kliyente, prefix, gateway pabalik, at ang sinusuportahang field na nagbibigay ng bawat isa. I-export ang config sa pamamagitan ng sinusuportahang mekanismo upang may sanggunian ang muling pagbuo, at i-verify ang serbisyo pagkatapos ng muling pagkonekta, pag-restart at pag-upgrade sa halip na pagkatapos lamang ng pagbabago.
Kapag may nasira, ihambing ang nabuong resulta sa rekord na iyon, sa halip na ibalik ang isang linyang walang paliwanag at umasa.sanggunian ng OpenVPN 2.6 ang lugar upang kumpirmahin kung paano nag-uugnayan ang route at iroute bago ka makipagtalo sa isang UI.
Checklist para sa susunod na pagbabago: pangalanan ang may-ari, sabihin ang tatlong-bahaging kontrata, i-export ang layunin, at muling subukan pagkatapos ng sariling mga kaganapan sa lifecycle ng appliance, hindi pagkatapos ng iyong pag-edit.