Журнал адладкі 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, і злучэнне працягне ламацца ў тым жа месцы, пакуль вы рэдагуеце файл, які ніхто не чытае.

Рэжым адладкі пакідае файлы

Працэс адладкі ад вытокаў запускае службу ўручную са сцягам адладкі, і гэты рэжым можа пакінуць згенераваныя канфігурацыйныя файлы часу выканання на месцы, калі злучэнне заканчваецца.

Гэтыя файлы змяшчаюць матэрыялы аўтэнтыфікацыі: папярэдне агульны ключ, уліковыя даныя або і тое, і іншае. Згенераваная канфігурацыя, скапіяваная ў акно чата, — гэта раскрыццё ўліковых даных, а не вытрымка з журнала. Выдаліце радкі з сакрэтамі, перш чым нешта перадаваць, і выдаліце каталог, калі расследаванне скончыцца. Стаўцеся да іх як да сакрэтаў, вымайце канкрэтныя радкі, патрэбныя для справаздачы, і выдаляйце іх пасля, а не ўстаўляйце каталог у заяўку.

Ручны асобнік таксама трэба ўзгадніць са звычайным. Запуск адладачнай копіі, калі служба ўжо валодае плагінам, стварае двух уладальнікаў і журнал, які змешвае абодвух, а гэта горш, чым поўная адсутнасць вываду адладкі.

Пасля гэтага аднавіце звычайны дапаможнік

Калі расследаванне скончыцца, спыніце ручны асобнік, выдаліце пакінутыя файлы часу выканання і падключыцеся зноў звычайным шляхам, каб наступны чалавек убачыў канфігурацыю, якая адпавядае рэчаіснасці.

Затым праверце вынік на тым узроўні, які не ўдаўся, а не на значку працоўнага стала:

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

Сеанс, які праходзіць аўтэнтыфікацыю, атрымлівае адрас і маршрутызуецца да патрэбнага пункта прызначэння, — гэта вынік, які вы адладжвалі. Маўклівы тэрмінал падчас няўдалай спробы паведамляе вам толькі дзе вывад не быў запісаны.