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 документира селекторите и опциите за изход, ако ви трябва форма, която версията на дистрибуцията поддържа.