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 не сприйняли за збій маршрутизації.

Запишіть фазу, метод і адресу в одну нотатку та поставте дату. Якщо той самий обліковий запис знову зірветься через місяць, ця нотатка — різниця між п'ятихвилинною перевіркою та новим розслідуванням. Збої на різних фазах — різні інциденти, навіть коли клієнт показує єдине вікно.