L2TP/IPsec не працює: відокремте IPsec, автентифікацію тунелю або вхід PPP

В одному з'єднанні L2TP/IPsec автентифікуються три речі, і лише одна з них стосується людини, яка набирає номер. IPsec доводить кінцеві точки тунелю, керівне з'єднання L2TP може повторно довести партнерів власним секретом, а потім PPP доводить обліковий запис користувача всередині сеансу. Збій на будь-якому етапі у вікні клієнта виглядає як загальна помилка входу, а в журналі сервера — зовсім інакше. Проходьте етапи по черзі й зупиняйтеся на першому невдалому, бо кожен етап нижче неперевіреного теж неперевірений.

Три етапи автентифікації, три різні особи

IPsec доводить, кому належать кінцеві точки, використовуючи попередньо розділений ключ або сертифікат. Ця особа належить машинам або шлюзам і ніколи — людині за клавіатурою. Коли партнери не можуть домовитися на цьому етапі, жоден пакет L2TP не передається.

Керівне з'єднання L2TP може додати другий, окремий обмін запит-відповідь, яким керує спільний секрет, обов'язковий для обох сторін.

RFC 2661 робить цю автентифікацію керівного з'єднання необов'язковою, що пояснює, чому та сама помилка дає різні симптоми на двох серверах. Розгортання, яке ніколи не налаштовувало секрет тунелю, повністю пропускає етап; те, яке налаштувало його лише з одного боку, зазнає невдачі ще до того, як PPP буде запропоновано. Далі PPP автентифікує користувача за PAP, CHAP або MSCHAPv2 і передає ім'я сховищу облікових записів, яке може бути локальним, у chap-secrets або в RADIUS. Неправильний пароль у цей момент усе одно залишає вас із робочим тунелем і невдалим сеансом.

Прочитайте точку зупинки, перш ніж змінювати конфігурацію

Почніть із ipsec --version, щоб знати, чи вивід стану належить strongSwan або Libreswan. Потім читайте журнал сервера, а не вікно клієнта, бо сервер записує, який етап відмовив.

Один рядок зазвичай вирішує заявку: скарга на IKE або пропозиції — це перший етап, повідомлення про керівне з'єднання — другий, а відмова методу PPP або облікового запису — третій. Скопіюйте цей рядок у заявку разом із позначкою часу. Здогадки з боку клієнта марнують єдиний доказ, який у вас уже є.

Тримайте ключовий матеріал і паролі поза цією вставкою; назва етапу скеровує роботу, а витік попередньо розділеного ключа знову відкриває заявку з гіршими наслідками.

Перший етап: чи має IPsec асоціацію?

Запустіть ipsec statusall на strongSwan або ipsec whack --status на Libreswan і пошукайте встановлену дочірню асоціацію з ненульовими лічильниками. ip xfrm state показує подання ядра на обох. Встановлена пара SA зі зростаючими лічильниками означає, що перший етап завершено і можна рухатися далі.

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

Зупиніться, поки асоціація відсутня. Правка параметрів PPP у цей момент нічого не змінює і приховує справжню несправність від наступної людини.

Другий етап: чи автентифікувалося керівне з'єднання L2TP?

Коли IPsec піднято, стежте за демоном L2TP: керівне з'єднання має досягти встановленого стану, інакше PPP не почнеться. Відмова на керівному з'єднанні означає, що секрет тунелю різниться між сторонами або одна сторона вимагає секрет, який інша ніколи не надсилає. Клієнти часто показують одне поле з міткою shared secret, і зазвичай воно належить IPsec, а не L2TP. Його заповнення не налаштовує секрет тунелю, а очищення не вимикає його.

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

Лише сеанс, який починає узгодження PPP, справді пройшов етап тунелю.

Третій етап: PPP відхиляє обліковий запис?

Збій PPP виглядає інакше ззовні: тунель встановлено, сеанс починається, а демон записує збій методу автентифікації або відмову облікового запису. Прочитайте метод, названий у цьому повідомленні. PAP і CHAP зазнають невдачі з різних причин, і сервер, який відхиляє один, відхилить клієнта, що пропонує лише його.

На сервері Linux перегляньте файл параметрів, який демон передає PPP, зазвичай /etc/ppp/options.xl2tpd, і підтвердьте, які методи приймаються і де вирішуються облікові записи. Ім'я, яке є в RADIUS, але відсутнє в локальному файлі секретів, збій чисто і виглядає як неправильний пароль. Потім перевірте, чи клієнт пропонує метод, який сервер приймає, а не сильніший, узгодження якого сервер відхиляє. Зміна попередньо розділеного ключа заради виправлення цього етапу марнує півдня і нічого не змінює.

Коли сеанс нарешті піднімається, призначення адрес, DNS і маршрути ще не перевірені, і кожен тихо збій по-своєму. Тримайте три рівні окремо у своїх нотатках: правильний ключ із неправильним обліковим записом завжди збій, а виправлення одного рівня ніколи не виправляє інший.