Patuloy na nag-uulit ang OpenVPN pagkatapos ng TLS error: paano ito ititigil

Kumokonekta ang kliyente, nabigo habang nag-uusap sa TLS, maghihintay at susubukan muli ang parehong server na may parehong resulta. Sa ilalim ng superbisor na nagre-restart ng nabigong proseso, ang mga pagtatangkang iyon ay nagiging walang katapusang loop sa journal, at ang unang diagnostic na linya ay nawawala sa abot. May opsyon ang OpenVPN na ginagawang nakikitang paglabas ang pagkabigong iyon sa halip na isa pang pagsubok. Ito ay setting para sa diagnosis at pagsubaybay, hindi pag-aayos, kaya ipares ito sa patakarang talagang hinahayaang manatiling naka-stop ang proseso.

Ang loop na nagtatago ng unang error

Ang nakikita mo ay paulit-ulit na bloke at hindi isang pagkabigo: isang pagtatangkang kumonekta, isang error sa TLS, isang paghinto, at pagkatapos ang parehong pagkakasunod-sunod. Bawat pag-uulit ay itinutulak ang orihinal na linya nang mas mataas sa journal. Kung nagre-restart ang unit kapag nabigo, maaaring tumagal nang ilang oras ang loop nang walang sinumang nagbabasa ng dahilan. Ang sintomas ay ang loop, kahit na ang pinagbabatayan na depekto ay isang problema lamang sa pakikipag-usap.

Tinitiis ito ng mga interactive na sesyon dahil maaaring mawala ang pansamantalang pagkabigo sa susunod na pagsubok. Hindi kayang tustusan ng mga awtomatikong koneksyon ang gayong optimismo: kailangang huminto ang proseso upang makita ng tao o monitor ang kalagayan.

Bago magbago ng kahit ano, ihatid ang isang buong siklo. Itala ang remote na address, ang yugto ng TLS na binanggit sa error, at kung lumalabas ba talaga ang proseso.

Ang mekanismo ng pag-uulit sa likod ng loop

Default ang pag-uulit dahil maraming walang kaugnayang timeout ang gumagamit ng parehong mekanismo. Itinatakda ng connect-retry ang pagitan ng mga pagtatangkang kumonekta, kayang limitahan ng connect-retry-max kung gaano kadalas sinusubukan ang bawat remote na entry, at pinamamahalaan ng resolv-retry ang paulit-ulit na paghahanap ng pangalan. Ang pagkabigo ng pakikipag-usap sa TLS ay dumarating sa mekanismong iyon bilang pangyayari sa transportasyon, kaya nag-iiskedyul ang kliyente ng isa pang pagsubok sa halip na mag-ulat. Nakakatulong ang default sa hindi matatag na link at nakakasama sa depektong hindi kayang gumaling.

Binabago lamang ng opsyong --tls-exit ang kaso ng pakikipag-usap. Inilalarawan ito ng manwal bilang paglabas kapag nabigo ang pakikipag-usap sa TLS, na mas makitid kaysa paglabas sa bawat error. Ang mga timeout, pagkabigo ng resolver at pagtanggi sa authentication ay pinapanatili ang sariling pag-uugali.

Gawing lumabas ang kliyente kapag nabigo ang TLS

Ilagay ang tls-exit sa profile na talagang nilo-load ng kliyente, o ibigay ang --tls-exit kapag sinimulan ito, at patakbuhin ito nang isang beses sa foreground. Basahin ang kalagayan ng paglabas at ang huling linya ng log, dahil iyon ang pinagbabatayan ng superbisor. Ang labas na hindi zero pagkatapos ng pagkabigo sa pakikipag-usap ang inaasahang resulta. Kung patuloy na nag-uulit ang proseso sa halip na matapos, wala ang opsyon sa profile na talagang nilo-load ng kliyente.

Ang superbisor ang nagpapasya kung nakikita ang labas na iyon. Ang systemd unit na may Restart=always o Restart=on-failure ay nagsisimula muli ng kliyente, kaya nagpapatuloy ang loop at mukhang walang ginagawa ang opsyon. Suriin ang patakaran bago sisihin ang kliyente:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Hinahayaang manatiling naka-stop ng Restart=no ang proseso, at nire-restart pa rin ng Restart=on-failure pagkatapos ng di-zero na kalagayan. Kung nais mong makita ang pagkabigo pero makabangon ang serbisyo mula sa walang kaugnayang pag-crash, itakda ang Restart=on-failure at gamitin ang StartLimitBurst at StartLimitIntervalSec para pigilan ang bagyo ng pag-restart. Pagkatapos basahin ang kalagayan ng unit upang kumpirmahin ang huling exit code: iniuulat iyon ng systemctl status, at pinapanatili ng journal ang unang error sa itaas ng mga restart.

Isulat ang pasya sa unit o sa mga tala ng profile. Ang profile na lumalabas kapag nabigo ang TLS ay mukhang aksidente sa susunod na tao maliban kung naitala ang dahilan. Sabihin kung aling mga pagkabigo ang dapat magpahinto sa proseso at alin ang dapat ulitin.

Patunayan gamit ang isang beses-lamang na endpoint

Para makita ang pag-uugali bago ito pagkatiwalaan, kopyahin ang profile at ituro ang kopya sa isang endpoint na tumatanggap ng TCP koneksyon pero hindi kailanman nagsasalita ng OpenVPN. Sapat na ang listener na sumasagot at pagkatapos ay tahimik. Sa tls-exit, dapat matapos ang kliyente kapag nabigo ang handshake; kung wala ito, dapat patuloy na umikot ang parehong profile. Gamitin ang kopya, hindi kailanman ang gumaganang profile.

Ihambing ang dalawang run sa kalagayan ng paglabas at sa unang linya ng error, hindi sa tagal ng bawat isa. Sinasabi ng kalagayan kung gumana ang opsyon, at sinasabi ng unang linya kung aling yugto ang nabigo.

Alisin ang test profile kapag tapos ka na. Ang kopyang may sadyang maling endpoint ay bitag para sa sinumang magsimula mamaya ng bawat profile sa direktoryo.

Mga yugtong hindi kayang maabot ng opsyong ito

Ang pagtanggi sa authentication ay mas huling yugto. Kung sinusuri ng server ang account at tinatanggihan ito, naipakipag-usap na ang TLS, kaya hindi gumagana ang tls-exit. Ang mga setting ng pag-uulit ng authentication ang susunod na tingnan, at mas mahalaga ang dahilan ng server kaysa sa huling linya ng kliyente. Ang maling password at kulang na certificate ay makakagawa ng katulad na mensahe sa panig ng kliyente.

Ang kulang na ruta, maling resolver o hindi maabot na gateway ay labas din sa opsyon, dahil hindi sila pagkabigo sa pakikipag-usap. Ang tahimik na pagkawala ng packet ang pinakamalinaw na kaso: depende sa kung gaano kalayo ang palitan, maaaring mag-ulat ang kliyente ng pagkabigo sa pakikipag-usap o basta ma-timeout.

Panatilihin ang pagkakaibang iyon sa iyong mga tala. Ang setting ay para sa diagnosis at pagsubaybay, hindi pag-aayos, kaya hindi nito inaayos ang kawalan ng tugma ng cipher, problema sa certificate o maling port. Ayusin muna ang dahilan ng nabigong pakikipag-usap, pagkatapos ay magpasya kung ang agarang paglabas ay bagay pa rin sa deployment.