Запуск OpenVPN да гатоўнасці сеткі не з'яўляецца збоем

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

Міф: запушчаная служба азначае працаздольны тунэль

Актыўны юніт даказвае, што працэс запушчаны і не завяршыўся. Ён не даказвае, што профіль загрузіўся, сертыфікат быў прыняты або далёкі бок адказаў. Пакаваны кліент можа хвілінамі круціцца ў цыкле паўтору, пакуль systemd паведамляе толькі пра поспех. Гэтая прорва паміж станам і паводзінамі — увесь прадмет.

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

Чытайце журнал для асобніка, а не стан юніта. Радок прычыны ёсць у журнале, а не ў этыкетцы стану.

Міф: налады паўтору ахопліваюць любы збой

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

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

Бесканечна паўтараць спробы з неадобраным сертыфікатам — не прычына прыбіраць праверку. Гэта прычына прачытаць памылку.

Міф: аднаго запускальніка дастаткова, таму дадайце яшчэ адзін

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

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

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

Што сапраўды патрабуе парадку

Парадак можа чакаць сканфігураванага адраса, і гэта ўсё, што ён гарантуе. network-online.target затрымлівае актывацыю, пакуль менеджар не палічыць сетку гатовай, а вызначэнне гатоўнасці залежыць ад менеджара. Ён нічога не кажа пра тое, ці развяжацца імя VPN, ці адкажа слухач і ці ўпусціў прыладу палонны партал.

Прачытайце ўсталяваны юніт і ўсе drop-in файлы, перш чым дадаваць залежнасці. Шырокі After= для кожнай сеткавай службы затрымлівае загрузку, не ўсталёўваючы злучэнне, якое вам сапраўды патрэбна.

Упарадкуйце залежнасць, якую можна праверыць, а ўсё астатняе правярайце пробным запытам гатоўнасці. Запыт, які адкрывае тунэль, лепшы за таймер, які ўгадвае.

Што адбываецца пасля першага ўздыму тунэля

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

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

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