L2TP се свързва, но PPP преговорите се провалят: коя фаза?

Тунелът IPsec се установява, клиентът показва защитен партньор и след това връзката умира, преди нещо да стигне до частната подмрежа. Тази празнина е PPP, който върши собствената си работа: опциите на връзката, автентикацията на потребителя и задаването на адрес се случват след като криптираният тунел вече съществува. Нищо в успешния обмен на първа фаза не дава парола или вътрешен адрес. Прочетете фазите по ред и отказът обикновено сам се назовава.

Тунелът е само първият слой

L2TP пренася PPP кадри в тунел, защитен с IPsec, което означава, че два независими преговора трябва да успеят, преди пакет да бъде маршрутизиран. Външният доказва, че двете страни са съгласни за ключове и идентичности. Вътрешният решава параметрите на връзката, дали потребителят се автентикира и какъв адрес получава клиентът.

Отказът вътре в PPP изглежда като счупен тунел във всеки клиент, който показва една индикаторна лампа. Ако се третира като проблем на тунела, се стига до преподписване на ключове, рестартиране на услуги и накрая до смяна на споделена тайна, която никога не е била грешна. Полезното разграничение е евтино: ако обменът с партньора е завършил и клиентът е преминал към подкана за потребителско име или към етап на автентикация, тунелът е наред. Всичко след тази точка принадлежи на PPP.

Прочетете последната фаза, която е успяла

Вървете по журнала напред и спрете на първата фаза, която не е завършила. Първо идва LCP, после автентикация, после IPCP за параметрите на IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Изтичане на времето за LCP означава, че двете страни така и не са се разбрали за основните опции на връзката, което е несъответствие в профила или блокиран вътрешен протокол, а не лоша парола. Явният отказ на автентикация е обратният случай: връзката е вдигната и едната страна е отказала данните за вход. Изтичане на времето за IPCP след успешна автентикация сочи към пулове от адреси или политика на сървъра. Всяко от тях има различен собственик и различно поправяне, затова фазата е по-важна от окончателния текст на грешката.

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

Съгласие между клиента и сървъра

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

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

Проверете адреса, не влизането

Завършеното влизане не е използваема сесия. IPCP договаря вътрешния адрес, а изчерпан пул или политика, която отказва клиента, все още може да остави свързан тунел без нищо за маршрутизиране.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

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

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