Дневник за отстрањивање грешака 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 позадински систем инсталиран пре него што дотакнете поставку за отклањање грешака. Опција евидентирања написана за strongSwan не ради ништа када ради libreswan, а веза ће наставити да не успева на истом месту док уређујете датотеку коју нико не чита.

Режим отклањања грешака оставља датотеке

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

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

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

Затим вратите нормалну помоћну програму

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

Затим проверите резултат у слоју који није успео, не на икони радне површине:

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

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