Які асобнік OpenVPN насамрэч выкарыстоўвае ваш профіль PiVPN?

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

Памочнік і дэман — розныя аб’екты

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

На хастзе systemd пачынайце з актыўнага юніта, а не са спісу папкі. Назва залежыць ад пакетавання: вобразы Debian і Raspberry Pi OS звычайна прапануюць шаблонны асобнік накшталт openvpn-server@server, а старэйшыя ўсталёўкі выкарыстоўваюць openvpn@server. Спытайце ў менеджэра, які з іх працуе, замест таго каб здагадвацца па назве файла.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

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

Прасачыце ланцужок канфігурацыі, які вырашыў дэман

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

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

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

Суппастаўце журнал працэсу, а не памылцы, якую памятаеце

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

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

Перабудова тунеля — не дыягнастычны крок

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

Тое ж датычыцца адключэння tls-auth або tls-crypt, паслаблення verify-x509-name, або адмовы ад другога фактара дзеля зялёнага статусу. Тунель, які злучаецца таму, што праверку прыбралі, — гэта іншая сістэма, а не адрамантаваная.

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

Што перадаць наступнаму чалавеку

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

Выдаліце прыватныя даныя перад тым, як дзяліцца. Прыватныя ключы, auth-user-pass файлы, матэрыял статычнага ключа і поўныя кліенцкія пакеты не месца ў тыкеце; назвы опцый і форма ланцужка звычайна дастатковыя для другой пары вачэй.

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