OpenVPN 3 Linux: прачытайце памылку D-Bus, перш чым адкочваць версію
Пяць службаў, адзін інтэрфейс. Суаднясіце памылку D-Bus з кампанентам, які адмовіў, праверце, ці існуе сеанс, і толькі потым выпраўляйце на гэтай мяжы.
Збоі ў OpenVPN 3 Linux прыходзяць як памылка метаду D-Bus з незнаёмым імем, і спакуса — адкаціць пакет і спадзявацца. Кліент не з'яўляецца адной праграмай: інтэрфейс каманднага радка размаўляе праз шыну са службамі, якім належаць профілі, сеансы, рухавік VPN і прывілеяваныя змены сеткі. Вызначыць, якая з гэтых пяці валодае няўдалым выклікам, — большая частка дыягностыкі, і гэта каштуе адной каманды замест адкоту. Далей ідзе менавіта гэтае рашэнне, у тым парадку, у якім збоі звычайна з'яўляюцца.
Пяць уладальнікаў за адной камандай
Важныя пяць працэсаў, і кожны мае ўласнае імя на шыне: інтэрфейс, які прымае вашу каманду, менеджар канфігурацыі, які захоўвае профілі і палітыку доступу да іх, менеджар сеансаў, якому належыць час жыцця сеансу, серверная частка, якая вядзе злучэнне праз OpenVPN 3 Core Engine, і служба налады сеткі, якая ўсталёўвае інтэрфейс, маршруты і параметры DNS. Памылка, якая называе аб'ект канфігурацыі, таму не з'яўляецца памылкай сервернай часткі, а серверная частка, якая не запускаецца, не з'яўляецца збоем аўтэнтыфікацыі. Аднесці паведамленне да аднаго з гэтых радкоў трэба да таго, як што-небудзь будзе зменена, бо кожны наступны крок залежыць ад таго, які радок ісцінны. Адгадванне радка — гэта шлях, на якім кароткае выпраўленне ператвараецца ў цэлы дзень працы з пакетамі.
Спытайце сістэмную шыну, якія службы прысутнічаюць, перш чым пытаць што-небудзь яшчэ, а затым пацвердзіце, што ўсталяваныя часткі згодныя наконт версіі. OpenVPN 3 Linux рэгіструе гэтыя службы як сістэмныя юніты, таму апытваць трэба сістэмную шыну, запыт версіі патрабуе адміністрацыйных правоў, а спіс, зроблены з --user, чытае ваш сеанс уваходу, дзе юніты ніколі не з'яўляюцца. Службы актывуюцца па патрабаванні, а некаторыя завяршаюцца ў прастоі, таму служба, якая адсутнічае да вашага першага запыту, проста яшчэ ні пра што не пыталася. Тры каманды ніжэй адказваюць пра наяўнасць, версію і стан юніта, не адкрываючы сеанс VPN.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'Што насамрэч даказвае кожны спіс
Уласныя ўяўленні кліента — самы танны даступны доказ, і кожнае з іх даказвае менш, чым здаецца. Профіль у спісе канфігурацыі паказвае, што профіль імпартаваны, і нічога пра тое, ці дазволена каму-небудзь падключацца з ім. Сеанс у спісе сеансаў паказвае, што аб'ект сеансу існуе, і нічога пра тое, ці завяршылася аддаленая аўтэнтыфікацыя.
openvpn3 configs-list
openvpn3 sessions-listШляхі аб'ектаў у гэтых вывадах пазначаюць кіраваныя аб'екты на шыне, а не файлы, таму іх нельга рэдагаваць, і шлях, запісаны раней, становіцца састарэлым у тую хвіліну, калі гэты сеанс адключаецца. Паўторнае выкарыстанне шляху з вашых нататак дае памылкі "no such object", якія не маюць нічога агульнага з VPN. Табліца этапаў ніжэй аддзяляе тое, што ўсталёўвае кожны крок злучэння, ад таго, што застаецца адкрытым, і рашэнне пра адкат абапіраецца менавіта на гэтую розніцу. Прачытайце радок, які адпавядае вашым доказам, і перачытайце тэкст памылкі яшчэ раз.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
Выклік злучэння вяртаецца раней, чым існуе тунэль
Выклік злучэння перадае вам сеанс для назірання і вяртаецца, таму знешне паспяховы выклік, за якім настае цішыня, — гэта нармальны прамежкавы стан, а не супярэчнасць. Інтэрфейс па-ранейшаму павінен адсочваць змены стану і адказваць на любы запыт узаемадзеяння. Профіль, якому патрэбны ўліковыя даныя і які не атрымлівае адказу, чакае ў стане, што выглядае дакладна як завіслая серверная частка. Гэты стан чакання варты пазнавання, бо ён адпраўляе людзей да не таго кампанента.
Пакуль спроба выконваецца, сачыце за спісам сеансаў і ўласным часопісам інтэрфейса для гэтага профілю. Сеанс, які так і не выходзіць з пачатковага стану, называе кампанент, які спыніўся, і часопіс звычайна называе яго ўжо ў першых радках. Трымайце імя профілю пад рукой, паколькі каманда часопіса прымае профіль, а не шлях сеансу, што з'яўляецца яшчэ адной прычынай перачытаць спіс замест паўторнага выкарыстання шляху.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6Чытанне часопіса аднаго кампанента без адкрыцця сеансу
Калі інтэрфейс не паведамляе нічога карыснага, перайдзіце да кампанента, які запісаў збой у часопіс, замест таго каб пачынаць новае злучэнне. Пры наладжаным журналізатары systemd-journald абмежаваны прагляд часопіса адміністратарам чытае падзеі аднаго кампанента, не закранаючы палітыку шыны і не адкрываючы сеанс, і гэта важна, бо дыягностыка, якая змяняе вымяраемую сістэму, даказвае вельмі мала. Фільтруйце па юніце, а не па тэгу syslog: асобныя службовыя юніты не гарантуюць агульнага ідэнтыфікатара, таму запыт па тэгу можа вярнуць пустую старонку, тады як сам юніт запісаў збой.
Запішыце чатыры палі, перш чым прасіць у кагосьці дапамогі: поўнае імя памылкі, задзейнічаныя службу і аб'ект, адзнаку часу і версіі ўсталяваных пакетаў. Менавіта гэта патрэбна суправаджальніку, і ніводнае з іх не патрабуе ўстаўляць профіль або ўліковыя даныя ў заяўку. Пашырэнне палітыкі доступу да шыны, каб прыглушыць памылку, — не дыягностыка, яно сцірае мяжу, якая называла кампанент за вас. Прыватны змест профіляў застаецца па-за агульнымі звесткамі з той жа прычыны, што і ўліковыя даныя.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>Выпраўленне мяжы, якая адмовіла
Кожны радок карты мае ўласнае выпраўленне, і радкі не замяняюць адзін аднаго. Адмоўленая аперацыя над профілем — гэта пытанне палітыкі і ўладання, тады як серверная частка, якая не актывуецца, — пытанне службаў і пакавання. Сервер, які адкідае аўтэнтыфікацыю, не з'яўляецца ні тым ні іншым, таму паўторныя змены пароля не могуць выправіць лакальную праблему актывацыі. Выбар няправільнага выпраўлення — гэта шлях, на якім праблема палітыкі ператвараецца ў пераўсталёўку.
Пасля змены пакетаў праверце ўзгодненае падтрымліванае ўсталяванне, а не капіруйце стары двайковы файл на яго месца. Кантраляваны адкат — законны адказ на пацверджаную рэгрэсію пры ўмове, што пакеты застаюцца сумяшчальнымі і што існуе шлях назад да падтрымліванага суправаджэння. Усталюйце гэты шлях да таго, як служба перастане запускацца, а не пасля.
Іншая платформа можа выкарыстоўваць тую ж базовую бібліятэку VPN, не падзяляючы шынныя службы Linux, таму падобны збой у Windows нічога не гаворыць пра гэты. Агляд D-Bus апісвае шляхі аб'ектаў, прадастаўленыя для канфігурацый і сеансаў, і менавіта на гэтай частцы архітэктуры трымаецца гэтая дыягностыка. Прачытайце яго адзін раз, і наступная памылка прыйдзе з ужо прывязаным да яе кампанентам.