OpenVPN працягвае паўтараць спробы пасля памылкі TLS: як гэта спыніць

Кліент падключаецца, церпіць няўдачу падчас узгаднення TLS, чакае і зноў спрабуе той жа сервер з тым жа вынікам. Калі працэсам кіруе супервізар, які перазапускае няўдалы працэс, гэтыя спробы ператвараюцца ў бясконцы цыкл у журнале, і першы дыягнастычны радок выпадае з поля зроку. OpenVPN прапануе параметр, які ператварае гэтую няўдачу ўзгаднення ў бачны выхад замест чарговай спробы. Гэта налада для дыягностыкі і нагляду, а не рамонт, таму спалучайце яе з палітыкай, якая сапраўды дазваляе працэсу застацца спыненым.

Цыкл, які хавае першую памылку

Вы бачыце не адну няўдачу, а блок, які паўтараецца: спроба злучэння, памылка TLS, паўза, а затым тая ж паслядоўнасць. Кожнае паўтарэнне штурхае зыходны радок усё вышэй у журнале. Калі юніт перазапускаецца пры няўдачы, цыкл можа працягвацца гадзінамі, пакуль ніхто не чытае прычыну. Сімптом — гэта цыкл, хоць асноўная непалада адна: праблема ўзгаднення.

Інтэрактыўныя сеансы трываюць гэта, бо часовы збой можа знікнуць пры наступнай спробе. Аўтаматызаваныя злучэнні не могуць дазволіць сабе такога аптымізму: працэс павінен спыніцца, каб чалавек або манітор убачыў стан.

Перш чым нешта змяняць, зафіксуйце адзін поўны цыкл. Запішыце аддалены адрас, этап TLS, названы ў памылцы, і ці выходзіць працэс наогул.

Механізм паўторных спроб за цыклам

Паўтор — гэта прадвызначэнне, бо некалькі незвязаных тайм-аўтаў выкарыстоўваюць адзін механізм. connect-retry задае інтэрвал паміж спробамі злучэння, connect-retry-max можа абмежаваць, як часта спрабуюць кожны аддалены запіс, а resolv-retry кіруе паўторнымі пошукамі імёнаў. Няўдача ўзгаднення TLS трапляе ў гэты механізм як падзея транспарту, таму кліент плануе чарговую спробу замест таго, каб паведаміць. Прадвызначэнне карыснае для няўстойлівага канала і шкоднае для непалады, якая не можа выгаіцца.

Параметр --tls-exit змяняе толькі выпадак узгаднення. Кіраўніцтва апісвае яго як выхад пры няўдачы ўзгаднення TLS, што вузей, чым выхад пры кожнай памылцы. Тайм-аўты, збоі рэзалвера і адмовы аўтэнтыфікацыі захоўваюць свае паводзіны.

Прымусіць кліент выходзіць пры няўдачы TLS

Змясціце tls-exit у профіль, які кліент сапраўды загружае, або перадайце --tls-exit пры запуску, і запусціце яго адзін раз на пярэднім плане. Чытайце код выхаду і апошні радок журнала, бо менавіта на код рэагуе супервізар. Ненулявы выхад пасля няўдачы ўзгаднення — гэта мэтавы вынік. Калі працэс працягвае паўтарацца замест завяршэння, параметр не ў тым профілі, які кліент сапраўды загружае.

Супервізар вырашае, ці будзе гэты выхад бачны. Юніт systemd з Restart=always або Restart=on-failure зноў запускае кліент, таму цыкл працягваецца, і параметр выглядае так, быццам нічога не робіць. Праверце палітыку, перш чым вінаваціць кліент:

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

Restart=no дазваляе працэсу застацца спыненым, а Restart=on-failure усё роўна перазапускае пасля ненулявога стану. Калі вы хочаце, каб збой быў бачны, але служба аднаўлялася пасля незвязаных аварыяў, усталюйце Restart=on-failure і выкарыстайце StartLimitBurst ды StartLimitIntervalSec, каб спыніць шквал перазапускаў. Затым прачытайце стан юніта, каб пацвердзіць апошні код выхаду: systemctl status паведамляе яго, а журнал захоўвае першую памылку вышэй за перазапускі.

Запішыце рашэнне ў юніт або ў нататкі профілю. Профіль, які выходзіць пры няўдачы TLS, выглядае як выпадак для наступнага чалавека, калі прычына не запісана. Укажыце, якія збоі павінны спыняць працэс, а якія варта паўтараць.

Дакажыце гэта на часовай канчатковай кропцы

Каб убачыць паводзіны перш чым ім давяраць, скапіруйце профіль і накіруйце копію на канчатковую кропку, якая прымае злучэнне TCP, але ніколі не гаворыць OpenVPN. Дастаткова слухача, які адказвае, а потым маўчыць. З tls-exit кліент павінен завяршыцца, калі рукапоціск не ўдаецца; без яго той жа профіль павінен працягваць цыкл. Выкарыстоўвайце копію, ніколі працоўны профіль.

Параўнайце два запускі па кодзе выхаду і па першым радку памылкі, а не па тым, колькі кожны доўжыўся. Код паказвае, ці спрацаваў параметр, а першы радок — які этап не ўдаўся.

Выдаліце тэставы профіль, калі скончыце. Копія з наўмысна няправільнай канчатковай кропкай — пастка для любога, хто пазней запускае кожны профіль у каталогу.

Этапы, да якіх гэты параметр не даходзіць

Адмова аўтэнтыфікацыі — гэта пазнейшы этап. Калі сервер ацэньвае ўліковы запіс і адмаўляе яго, TLS ужо ўзгоднены, таму tls-exit не спрацоўвае. Налады паўтору аўтэнтыфікацыі — наступнае месца для пошуку, і прычына сервера важнейшая за апошні радок кліента. Няправільны пароль і адсутны сертыфікат могуць даваць падобныя паведамленні на баку кліента.

Адсутны маршрут, няправільны рэзалвер або недасягальны шлюз таксама па-за параметрам, бо гэта не няўдачы ўзгаднення. Ціхая страта пакетаў — найменш відавочны выпадак: у залежнасці ад таго, як далёка зайшоў абмен, кліент можа паведаміць пра няўдачу ўзгаднення або проста выйсці па тайм-аўце.

Трымайце гэтае размежаванне ў нататках. Налада прызначана для дыягностыкі і нагляду, а не для рамонту, таму яна не выпраўляе неадпаведнасць шыфраў, праблему сертыфіката або няправільны порт. Спачатку выпраўце прычыну няўдалага ўзгаднення, а потым вырашыце, ці неадкладны выхад яшчэ падыходзіць для разгортвання.