Дневникът за отстраняване на грешки на L2TP е празен? Грешката вероятно е в системния дневник

Стартирате помощника за L2TP с отстраняване на грешки, гледате терминала и той спира без нищо полезно на екрана. Това не е счупен флаг за отстраняване на грешки. Връзката NetworkManager L2TP е четири взаимодействащи процеса и само някои от тях пишат в терминала, който наблюдавате. Останалите доказателства са в дневника, на един филтър разстояние.

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

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

Помощната услуга координира тези части и отпечатва собствения си напредък. Услугата IPsec и pppd обикновено докладват през системния дневник, поради което терминалът показва провалена връзка, докато причината стои във файл, който не сте отворили.

Това разделение също обяснява защо грешка в PSK и грешка в паролата изглеждат еднакво от работния плот: и двете дават общо прекъсване, а етапът, който се е провалил, се вижда само в изхода на отделните процеси. Точно затова дневникът има значение тук. Едно общо съобщение на работния плот, четири възможни автора зад него.

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

Възпроизведете веднъж, с известен профил и известно време, после четете тесен прозорец, а не цялото зареждане. Повтарянето на опити при промяна на настройките превръща дневника в смесица, която не може да се тълкува.

Тези команди избират участващите процеси за текущото зареждане и си струва да потвърдите пътя на приставката в своята дистрибуция:

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 е инсталиран, преди да пипате настройка за отстраняване на грешки. Опция за дневник, написана за strongSwan, не прави нищо, когато работи libreswan, и връзката ще продължи да се проваля на същото място, докато редактирате файл, който никой не чете.

Режимът за отстраняване на грешки оставя файлове

Работният процес за отстраняване на грешки от upstream стартира услугата ръчно с флаг за отстраняване на грешки и този режим може да остави генерирани конфигурационни файлове за време на изпълнение, когато връзката приключи.

Тези файлове съдържат материали за удостоверяване: предварително споделения ключ, идентификационни данни или и двете. Генерирана конфигурация, копирана в чат прозорец, е разкриване на идентификационни данни, а не извадка от дневник. Премахнете редовете с тайни, преди да споделите нещо, и изтрийте директорията, когато разследването приключи. Отнасяйте се с тях като с тайни, извлечете конкретните редове, които ви трябват за доклад, и ги изтрийте след това, вместо да поставяте директория в билет.

Ръчното копие също трябва да се координира с нормалното. Стартирането на копие за отстраняване на грешки, докато услугата вече притежава приставката, създава двама собственици и дневник, който смесва и двамата, което е по-лошо от пълна липса на изход за отстраняване на грешки.

След това възстановете нормалния помощник

Когато разследването приключи, спрете ръчното копие, премахнете запазените файлове за време на изпълнение и се свържете отново по нормалния път, за да види следващият човек конфигурация, която отговаря на реалността.

След това проверете резултата на слоя, който се е провалил, а не на иконата на работния плот:

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

Сесия, която се удостоверява, получава адрес и маршрутизира към желаната дестинация, е резултатът, който сте отстранявали. Тихият терминал по време на неуспешен опит ви казва само къде изходът не е бил записан.