Pagkabigo ng client-connect sa OpenVPN: garantisado ba ang paglilinis sa disconnect?
Ang tinanggihang kliyente ay hindi nagbabalik ng patakaran ng firewall o naisulat na rekord. Ihambing ang kontrata ng callback sa rollback na kailangang gawin ng iyong hook nang mag-isa.
Kapag ang script na client-connect ay lumabas na may di-sero na code, tinatanggihan ng OpenVPN ang kliyente, at karaniwang inaakala ng mga operator na ang katumbas na script na client-disconnect ang mag-aayos ng lahat. Kadalasan ay hindi ito tumatakbo, dahil ang pagproseso ng disconnect ay nakadepende sa kung ano ang naisagawa ng yugto ng connect. Ang ituring na isang mekanismo ang pagtanggi at rollback ang siyang gumagawa ng bigong pag-login na maging tumagas na patakaran ng firewall o ulilang rekord. Dalawang magkahiwalay na obligasyon ito, at isa lamang ang awtomatiko. Basahin ang sariling landas ng paglabas ng hook bago sisihin ang server sa naiwang estado.
Ang di-sero na paglabas ay tumatanggi sa kliyente; hindi nito binabalik ang iyong trabaho
Ang estado ng paglabas ng client-connect ay desisyon sa pagtanggap. Ang sero ay nangangahulugang tanggapin, ang anumang iba pa ay nangangahulugang gibain ang instance bago ito ganap na maitatag. Wala sa kontratang iyon ang sumusuri sa nagawa na ng script sa labas ng mundo. Kung nagdagdag ang script ng patakaran ng iptables, nagsulat ng hilera o nagtaas ng counter, ang mga pagbabagong iyon ay nakakaligtas sa pagtanggi.
Ganito rin ang asimetriya sa mga plugin, kung saan maraming function na connect ang maaaring tumakbo para sa isang instance. Ang huling pagkabigo ay hindi bumabaligtad sa naunang tagumpay, at ang naunang function ay walang paraan para malaman na nabigo ang kapatid na function.
Ang pagtanggi ay awtomatiko, ang paglilinis ay hindi
Ang manwal ng OpenVPN 2.6 ay nag-uugnay ng pagproseso ng client-disconnect sa tagumpay ng naunang pagproseso ng connect. Ang dokumentadong eksepsiyon ay sumasaklaw sa mga cascading chain: kung ang isang hakbang ng connect ay nagbalik na ng tagumpay, ang katumbas na mga hakbang ng disconnect ay tumatakbo pa rin kapag giniba ang instance, kahit na nabigo ang huling hakbang ng connect. Ang eksepsiyong iyon ay makitid at nakadepende sa kung ilang callback ang na-configure, kaya ang pagsubok sa isang shell script ay walang sinasabi tungkol sa isang chain.
I-map ang aktwal na configuration bago magdisenyo sa paligid nito: aling script, aling plugin at sa anong pagkakasunod-sunod tumatakbo. Inililista ng talahanayan sa ibaba kung ano ang iniiwan ng kalahating-tapos na setup.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
Ang bawat hilera ay nagtatapos nang pareho para sa kliyente at naiiba para sa host. Hindi matukoy ng kliyente kung alin sa mga ito ang nangyari, kaya dapat ibalik ng hook ang ginawa nito bago ibalik ang estado ng pagkabigo.
Magbayad-pinsala sa loob ng script na nabigo
I-validate ang lahat ng kaya bago hawakan ang pinagsasaluhang estado: mga field ng sertipiko, pagkakaroon ng address, ang grupo kung saan kabilang ang kliyente. Ang pinakamurang pagtanggi ay ang nangyayari bago ang anumang paglalaan. Kapag ang setup ay sumasaklaw sa maraming panlabas na operasyon, itala kung alin ang natapos at ibalik ang mga ito sa kabaligtarang pagkakasunod-sunod bago ibalik ang estado ng pagkabigo.
Isang kongkretong kaso: ang script ay gumagawa ng firewall entry bawat kliyente, pagkatapos ay nabigo sa pagsulat ng hilera ng estado na naglalarawan dito. Dapat alisin ng sangay na nabigo ang entry na ginawa lang nito at pagkatapos ay lumabas na may di-sero na code. Ang paghihintay sa isang kaganapang disconnect na maaaring hindi kailanman maiiskedyul ay kung paano nabubuhay ang isang patakaran nang mas mahaba kaysa sa session na itinakda para dito.
Gawing idempotent at may may-ari ang kompensasyon
Ang paglilinis ay dapat ligtas na patakbuhin nang dalawang beses at tumpak sa kung ano ang maaaring tanggalin. Ang huling kaganapan mula sa naunang pagtatangka ay hindi dapat magtanggal ng paglalaan ng mas bagong session dahil lang sa parehong nagbabahagi ng karaniwang pangalan o na-recycle na address ng tunnel. Itala ang partikular na handle o operation id kasama ng resource, at tanggalin sa pamamagitan ng key na iyon sa halip na sa pangalan. Ang mga transaksyon ng database ay tumutulong lamang sa sariling mga pagbabago ng database; ang patakaran ng firewall sa labas ng hangganang iyon ay nangangailangan ng tahasang hakbang ng kompensasyon.
Ipagpalagay na ang proseso ay maaaring mamatay sa pagitan ng pagbabago at paglilinis, at magdagdag ng reconciler na naghahambing ng panlabas na estado sa listahan ng mga tinanggap na kliyente ayon sa iskedyul.
Subukan ang tatlong landas na talagang naiiba
Sanayin ang tatlong kaso: pagtanggi bago may mailaan, isa pagkatapos ng bahagyang paglalaan, at isang normal na tinanggap na session na nagtatapos mamaya. Ang tatlong iyon ay gumagawa ng magkaibang linya ng log at magkaibang nalalabi. I-verify ang panlabas na estado pagkatapos ng bawat isa, hindi lamang ang mensahe ng pagkabigo ng kliyente, dahil ang pagkabigo ng kliyente ang inaasahang resulta sa dalawa sa tatlo.
I-log ang yugto ng hook, ang estado ng paglabas at kung ano ang inilaan o pinakawalan, nang walang mga kredensyal. Ang log ng hook na nagngangalan sa resource na ginawa nito ang siyang gumagawa sa tumagas na patakaran na mahanap anim na buwan mamaya.