Празен дневник за отстранување грешки на L2TP? Грешката е веројатно во journal

Ја стартувате помошната програма L2TP со отстранување грешки, гледате во терминалот и таа запира без ништо корисно на екранот. Тоа не е расипано знаменце за отстранување грешки. NetworkManager L2TP врската е четири процеси што соработуваат, и само некои од нив пишуваат во терминалот што го гледате. Останатите докази се во journal, на еден филтер оддалеченост.

Четири процеси, две одредишта на дневникот

Врската започнува со IPsec, кој во зависност од инсталацијата е libreswan или strongSwan. Потоа L2TP демонот, традиционално xl2tpd, а во некои изградби kl2tpd, го води тунелот. На крајот pppd се занимава со автентикација и адресирање во него.

Помошната служба ги координира тие делови и го печати сопствениот напредок. IPsec демонот и pppd обично известуваат преку системскиот journal, поради што терминалот покажува врска што не успева, а причината е во датотека што не сте ја отвориле.

Оваа поделба исто така објаснува зошто грешка во PSK и грешка во лозинка изгледаат исто од работната површина: обете создаваат општо исклучување, а етапата што не успеа е видлива само во излезот на секој процес. Тоа е целата причина зошто journal е важен овде. Една општа порака на работната површина, четири можни автори зад неа.

Соберете еден обид, потоа прочитајте го редоследот

Репродуцирајте еднаш, со познат профил и познато време, потоа читајте тесен прозорец наместо целото подигање. Повторувањето обиди додека менувате поставки го претвора дневникот во смеса што не може да се протолкува.

Овие наредби ги избираат процесите учесници за тековното подигање, а патеката на приклучокот вреди да се потврди во вашата дистрибуција:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Повторените полиња во еден повик ја избираат унијата на тие процеси, што го задржува редоследот во временски ред. Во систем заснован на Debian еквивалентното барање е dpkg -L; поентата е да се најде каде помошната програма навистина живее пред да се обиде да се изврши рачно.

Три услови го одредуваат следниот чекор

Прочитајте ја првата етапа што не успеа, потоа изберете соодветно. Ако IPsec пријави неуспех на предлог или на автентикација на партнерот, тунелот никогаш не се формира, и менувањето на PPP лозинката не може да помогне.

Ако тунелот се формира и pppd го одби пријавувањето, заедничката тајна веќе беше во ред и проблемот со акредитивите е еден слој погоре. Ако pppd преговараше за адреса, а неуспехот се појави подоцна, двете работат и преостанатиот проблем е рутирање, DNS или сопствената политика на серверот.

Овие три гранки покриваат речиси секое општо исклучување, и нив ги одредува тоа кој процес ја запишал последната грешка, а не тоа која порака за грешка изгледа најзагрижувачки.

Вреди да се потврди и кој IPsec backend е инсталиран пред да се допре поставка за отстранување грешки. Опција за евидентирање напишана за strongSwan не прави ништо кога работи libreswan, и врската ќе продолжува да не успева на истото место додека ја уредувате датотеката што никој не ја чита.

Режимот за отстранување грешки остава датотеки

Оригиналниот тек на работа за отстранување грешки ја стартува службата рачно со знаменце за отстранување грешки, и тој режим може да остави генерирани конфигурациски датотеки за време на извршување на местото кога врската завршува.

Тие датотеки содржат материјал за автентикација: претходно споделениот клуч, акредитивите или обете. Генерирана конфигурација копирана во прозорец за разговор е откривање акредитиви, не извадок од дневник. Отстранете ги тајните редови пред да споделите нешто и избришете ја папката кога истрагата завршува. Третирајте ги како тајни, извлечете ги конкретните редови што ви се потребни за извештај и избришете ги потоа, наместо да залепите папка во тикет.

Рачната инстанца исто така мора да се усогласи со нормалната. Стартување копија за отстранување грешки додека службата веќе го поседува приклучокот создава два сопственици и дневник што ги меша обете, што е полошо од воопшто без излез за отстранување грешки.

Потоа вратете ја нормалната помошна програма

Кога истрагата завршува, запрете ја рачната инстанца, отстранете ги задржаните датотеки за време на извршување и поврзете се повторно по нормалниот пат за следната личност да види конфигурација што одговара на реалноста.

Потоа проверете го резултатот на слојот што не успеа, не на иконата на работната површина:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Сесија што се автентицира, добива адреса и се рутира кон предвиденото одредиште е резултатот што го отстранувавте од грешки. Тивок терминал за време на неуспешен обид ви кажува само каде излезот не е запишан.