Muling pagkonekta ng kliyenteng OpenVPN: tatlong kontrol, tatlong saklaw

May humihiling na muling ikonekta ang kliyenteng VPN, at ang hiling na iyon ay maaaring mangahulugan ng tatlong magkakaibang bagay. Maaaring mangahulugan ito ng pag-drop ng isang authenticated na sesyon, pagpapaalam sa bawat kliyente na aalis ang isang UDP server, o pag-restart ng mismong daemon. Bawat isa ay may ibang lawak ng epekto, at ang maling pagpili ay ginagawang pagkawala ng serbisyo ang isang pag-aayos para sa isang user. Ang saklaw ang desisyon, at ang utos ay sumusunod mula rito.

Itanong kung sino ang dapat maapektuhan bago itanong kung aling kontrol ang gagamitin.

Isang instance: ang management interface

Maaaring ilista ng naka-configure na management interface ang mga konektadong instance at i-drop ang eksaktong isa sa kanila. Bawat sesyon ay may dalang client identifier, at client-kill CID ay tumatarget sa identifier na iyon kaysa sa isang karaniwang pangalan. Basahin ang live na identifier mula sa kasalukuyang status output, dahil ang value na kinopya mula sa lumang log ay tumutukoy sa sesyon na wala na. Ang pag-drop ng instance ay tinatapos ang koneksyong iyon at wala nang iba.

Hindi nito ginagarantiya ang bagong koneksyon. Kung babalik ang kliyente ay depende sa mga setting ng retry, natitirang remote entry, mga pangangailangan sa authentication at kung tumatakbo pa ang supervising application. Ang bumabalik na kliyente ay nakakakuha ng bagong identifier, at dahil dito ang paghahambing ng mga identifier ang tanging maaasahang paraan upang makilala ang luma sa bago.

Ang UDP exit notice ay hindi utos para sa bawat kliyente

explicit-exit-notify ay isang configuration directive tungkol sa mga exit at restart event. Sa isang UDP client sinasabi nito sa peer na nagtatapos ang sesyon, at kinokontrol ng numeric argument kung ilang beses inuulit ang notice. Kapag tumatakbo ang server sa UDP nagpapadala ito ng restart control message sa mga konektadong kliyente, at ang mga dokumentadong value ay nagtatangi ng muling pagkonekta sa parehong server mula sa paglipat sa ibang remote entry. Iyon ay isang lifecycle signal na may malawak na audience.

Walang anuman dito ang pumipili ng arbitraryong kliyente sa arbitraryong sandali. Ang ituring itong button ng muling pagkonekta ay umaabot sa bawat konektadong sesyon nang sabay.

Ang mga signal ay kumikilos sa proseso, hindi sa sesyon

SIGUSR1 humihiling sa tumatakbong proseso na i-restart ang koneksyon nito nang hindi binabasa muli ang configuration, at ang mga opsyon sa persistence ang nagtatakda kung ano ang makakaligtas sa restart na iyon. SIGHUP ay mas malayo: binabasa nitong muli ang configuration file at muling binubuksan ang mga resource nito. SIGTERM at SIGINT ay humihiling ng maayos na shutdown. Ito ay mga operasyon sa antas ng proseso: sa server na may maraming kliyente, naaapektuhan nila ang bawat sesyong dala ng proseso, hindi lamang ang nakasaad sa ticket.

Kapag tumatakbo ang proseso sa ilalim ng service manager, gamitin ang sariling kontrol ng manager sa halip na magpadala ng signal sa PID na nakita mo sa listahan ng proseso. Basahin ang unit upang makita kung aling signal ang ipinapadala ng manager, dahil magkaiba ang ginagawa ng restart at reload sa parehong daemon.

Itakda ang saklaw bago piliin ang kontrol

Tatlong tanong ang nagtatakda nito. Sino ang dapat maapektuhan: isang user, bawat kliyente ng isang server, o ang daemon at lahat ng dala nito. Ano ang dapat makaligtas: ang configuration, ang estado ng tunnel, o wala sa dalawa. Sino ang may awtoridad: ang management integration, ang may-ari ng serbisyo, o ang network operator na kumokontrol sa exit notice. Sagutin ang mga iyon at isang kontrol lang ang bagay.

Ang pagdagdag ng hindi authenticated na control listener para makakuha ng button ng muling pagkonekta ay nagbibigay sa sinumang makakaabot sa port ng higit pa sa button na iyon.

I-verify ang bagong sesyon, hindi ang pagdisconnect

Ang event ng pagdisconnect ay nagpapatunay na natapos ang lumang sesyon. Wala itong sinasabi tungkol sa bagong sesyon na nagpapatunay, tumatanggap ng address, nag-i-install ng ruta o umaabot sa resource na kailangan ng user. Suriin ang bagong identifier, pagkatapos ang estado ng tunnel, pagkatapos ang isang tunay na resource. Ang tatlong hakbang na iyon ang pagkakaiba ng muling pagkonekta at ng gumaganang koneksyon.

Isulat ang saklaw sa change record. 'Muling ikinonekta ko ang kliyente' ay hindi paglalarawan kapag ang kliyente ay isa sa apatnapu sa shared server.