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

Дзве формы захоўвання, адзін дырэктыў

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

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

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

Як убудаваны блок ператвараецца ў аб'ект

Убудаванае змесціва вымаецца з канфігурацыі і перадаецца парсеру PEM як тэкст. Гэты парсер чакае звычайныя межы: радок BEGIN, карысную нагрузку base64 і адпаведны радок END. Калі блок быў абрэзаны няўдалым капіраваннем, абгорнуты HTML старонкай загрузкі або адкрыты ў рэдактары, які нармалізаваў працяжнікі, парсер памыляецца на змесціве, якое выглядае прысутным.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Менавіта таму фармулёўка памылкі ўводзіць у зман. Слова inline апісвае, куды глядзеў загрузчык, а не тое, што ён там знайшоў. Файл, названы ў канфігурацыі, і ўбудаваны ў яе аб'ект могуць даць аднолькавую скаргу, калі асноўныя байты непрыдатныя.

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

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Як развязваецца спасылка на шлях

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

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

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

Што памылка парсера можа і не можа сказаць

Збой разбору лакалізуе праблему на адзін уваход і адну стадыю. Ён не кажа, якую з двух форм захоўвання выкарыстаў кліент, і не кажа, ці быў бы аб'ект прыняты. Гэта асобныя пытанні з асобнымі доказамі.

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

Трымайце адчувальную палову па-за публічнымі справаздачамі, пакуль вядзецца расследаванне. Дзяліцеся імёнамі дырэктываў, тэкстам памылкі і структурай блока, выдаліўшы матэрыял ключа і любую ідэнтыфікуючую нагрузку. Дапаможнік openvpn(8) апісвае абедзве формы дырэктываў файла і паводзіны працоўнага каталога за імі.

Падобныя артыкулы