journalctl для журналаў VPN: які юніт валодае злучэннем?

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

Параўнайце трох звычайных уласнікаў

Кліенцкая служба OpenVPN звычайна ўяўляе сабой экзэмпляр юніта, названы па профілі, напрыклад [email protected]. Яе паведамленні ўключаюць шлях да канфігурацыі, разбор опцый, рукапоціск TLS і ўсталяванне маршруту, якое выконвае кліент.

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

NetworkManager валодае створанымі ім профілямі, і яго паведамленні жывуць пад NetworkManager.service, нават калі асноўны плагін — гэта дапаможнік VPN. Запытайце і менеджэр, і дапаможны юніт, калі профіль кіруецца такім чынам.

Звузьце запыт да аднаго юніта і інтэрвалу

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

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

Прачытайце першую няўдалую стадыю

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

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

Не змешвайце няўдалую службу з ручным кліентам

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

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

Дайце фрагмент, а не экспарт

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

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