journalctl за VPN дневнике: која јединица поседује везу?
OpenVPN, wg-quick и NetworkManager пишу у различите јединице. Изаберите власника, сузите временски прозор, затим прочитајте прву неуспелу фазу редом.
Почните од јединице 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 документује селекторе и опције излаза ако вам треба облик који верзија дистрибуције подржава.