OpenVPN не знаходзіць ca.crt, хоць профіль і загружаецца

Сэрвіс запускаецца, чытае профіль без скаргаў, а потым памірае на радку, які выглядае не звязаным: ён не можа адкрыць ca.crt. Нічога ў сертыфікаце не змянілася, а шлях да профілю ў unit-файле абсалютны. Менавіта гэтае спалучэнне і ёсць падказка. Шлях, які вы перадалі, паказвае на адзін файл, а імёны ўнутры гэтага файла разлічваюцца зусім у іншым месцы, таму запуск, які выглядае цалкам кваліфікаваным, усё яшчэ можа чытаць свае ключы з каталога, якога ніхто не меў на ўвазе.

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

Шлях да профілю — не базавы каталог

Уявіце працэс, які стартуе ў /tmp і атрымлівае /etc/vpn/prod/tenant-a.ovpn. Унутры гэтага профілю радок ca ca.crt паказвае адносны шлях. Нішто ў аргуменце, які знайшоў профіль, не перапісвае гэтае імя, таму працэс шукае /tmp/ca.crt і паведамляе пра адсутны файл.

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

Што размяжоўвае даведнік: --config і --cd

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

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

Сэрвіс стартуе ў іншым месцы

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

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

Пасля пошуку: правы, chroot і пясочніца

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

Тры звычайныя варыянты даюць аднолькавую памылку. Файл чытальны толькі для root, а сэрвіс скідае прывілеі перад яго адкрыццём. Unit усталёўвае ахоўны прагляд файлавай сістэмы, які не ўключае каталог профілю. Дэман працуе з chroot, таму шлях, які існуе на хаце, не існуе ўнутры гэтага прагляду.

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

Дакажыце выпраўленне ўласным запускам

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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