Який етап VPN не спрацював: IPsec, керування L2TP чи автентифікація PPP
Знайдіть останній успішний етап і виправте лише той шар: IPsec, канал керування L2TP, автентифікацію PPP або видачу адреси.
Ви змінили пароль і нічого не зрушило, бо збій ніколи не був у PPP. L2TP/IPsec повідомляє про одну помилку з'єднання для п'яти цілком різних передач, і кожна передача має власне виправлення. Працюйте у зворотному напрямку: знайдіть останній успішний етап і змінюйте лише те, що йде після нього. Порядок нижче також визначає, які докази збирати першими.
Дайте відповідь на чотири питання по черзі
Примусово запустіть нову спробу, бо деякі клієнти показують попередню помилку, доки профіль не буде від'єднано й приєднано знову. Потім дайте відповідь: чи була асоціація безпеки IPsec, чи з'явилися керівне з'єднання L2TP і виклик, чи PPP дійшов до рішення про автентифікацію і чи IPCP дав клієнтові адресу? Перше ні — це етап, який ви виправляєте. Усе після нього не перевірено, тож відхилене ім'я користувача нічого не доводить, коли асоціації ніколи не було.
Перед порівнянням синхронізуйте годинники на обох кінцях. Повторна спроба, яка очистила IPsec і зазнала невдачі на PPP, виглядає як один збій, коли клієнт показує лише останнє повідомлення, а журнал сервера ще зберігає попередню спробу. Читайте за міткою часу, а не за найгучнішим рядком.
Коли у вас лише скриншот користувача, покладайтеся на найдешевше розділення: хибний попередньо спільний ключ і xl2tpd, який ніколи не відповідає, дають той самий текст у діалозі Windows, але одному потрібен секрет, змінений на обох кінцях, а іншому — запущений демон або правило брандмауера на самому сервері. Пристрій посередині не може відкинути внутрішній 1701 після того, як IPsec у транспортному режимі його загорнув, тож не шукайте фільтр шляху, якого немає.
Чим насправді володіє кожен шар
IPsec захищає пакети між двома вузлами; L2TP несе сеанс PPP усередині цього захищеного шляху, тому RFC 3193 визначає транспортний режим, а не власний тунель. Мітка клієнта каже L2TP, тож тунель і вхід відчуваються одним механізмом. Це не так: керівне з'єднання L2TP автентифікує кінці тунелю там, де розгортання це вмикає, а PPP окремо автентифікує користувача через CHAP, PAP або MS-CHAPv2 згідно з політикою сервера.
Це розділення пояснює два секрети, які люди постійно плутають. Попередньо спільний ключ автентифікує вузли IPsec. Ім'я користувача й пароль ідентифікують користувача для PPP. Повторне введення спільного секрету Windows у профілі, що автентифікується сертифікатами, нічого не змінює на етапі, який збоїть, а редагування пароля PPP не може дати відсутній захищений канал. Така сама стриманість стосується перевірки автентичності: не вимикайте автентичність вузла чи перевірку сертифіката, щоб отримати тунель, бо тоді з'єднується шлях, а не вузол.
Автентифікація також не кінець PPP. Після прийняття користувача IPCP узгоджує адресу клієнта та параметри DNS і WINS, які сервер готовий видати. Клієнт може пройти CHAP або MS-CHAPv2 і все одно залишитися без адреси, а це збій усередині PPP, а не проблема маршрутизації. Звичайний L2TP без IPsec залишається чинним і незахищеним, тож успішне з'єднання ніколи не доводить, що трафік захищений; перевіряйте, що вимагає сервер, а не мітку клієнта.
Вирішуйте за першим відсутнім етапом
Читайте таблицю за першим відсутнім пунктом, зліва направо. Правий стовпець — єдина робота, що має сенс у цей момент; усе ліворуч уже доведено, а повторна перевірка спалює вікно простою, не додаючи інформації.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Три рядки заслуговують на попередження. Рядок 1701 — це місце, куди зазвичай потрапляють клієнти Windows за NAT: асоціація завершується, далі нічого не надходить, і причина — інкапсуляція, а не поганий пароль. Рядок IPCP — той, який помилково читають як проблему маршруту, бо Windows загортає відсутню адресу в помилку 720, а значок у лотку лише каже, що з'єднання не вдалося; цей збій стоїть після автентифікації й до маршрутизації. Останній рядок зовсім не збій IPsec, хоча значок каже «від'єднано».
Команди, що розділяють шари
На сервері Linux зі strongSwan swanctl --list-sas перелічує встановлені асоціації з автентичністю вузла, а ipsec statusall охоплює старіші хости strongSwan і libreswan. Нижче ip xfrm state показує фактичні асоціації ядра, а ss -lunp | grep 1701 доводить, де прив'язаний xl2tpd. Запустіть xl2tpd -D на передньому плані, щоб побачити керівні з'єднання й виклики, і ввімкніть налагодження pppd у /etc/ppp/options.xl2tpd, щоб побачити запропонований метод і відповідь.
Коли журнали показують успішну автентифікацію, наступне питання — чи завершився IPCP. Перевірте, чи в ip range у розділі [lns default] файлу /etc/xl2tpd/xl2tpd.conf ще є вільні адреси і чи /etc/ppp/options.xl2tpd справді несе ms-dns та ms-wins, якщо клієнт їх очікує. Вичерпаний пул і відсутній параметр DNS виглядають на дроті по-різному: перший лишає клієнта без адреси й з 720, другий дає адресу, але без розв'язувача, тож імена не працюють, а ping за сирими адресами йде. Ні те ні те не виправляється повторним уведенням пароля.
На клієнті плагін L2TP у NetworkManager записує розмову pppd у журнал, тож journalctl -u NetworkManager -b зазвичай відділяє тунель піднято, автентифікацію відхилено від тунелю немає взагалі. У Windows Get-VpnConnection повідомляє реальні параметри автентифікації профілю, а події RasClient у розділі Application переглядача подій називають збійний компонент. Коли діалог надто неясний, увімкніть netsh ras set tracing * enable.
Записи вимагають однієї обережності. У транспортному режимі IPsec внутрішній UDP 1701 зашифрований, тож запис на зовнішньому інтерфейсі показує ESP або UDP 4500 за NAT-T і зовсім не L2TP. Відсутність 1701 у записі очікувана і не є доказом закритого порту; стежте, чи рухаються лічильники ESP або 4500.
NAT, MTU і маршрути: де стек вводить вас в оману
NAT ламає припущення ще до того, як щось автентифіковано. ESP — власний протокол IP, тож пристрій, що перекладає, відкидає його, якщо вузли не інкапсулюють; саме це забезпечує UDP 4500. На сервері Windows, який сам стоїть за домашнім маршрутизатором або хмарним шлюзом NAT, етап IPsec зривається з помилкою 789, доки AssumeUDPEncapsulationContextOnSendRule не буде встановлено в 2 під ключем PolicyAgent і машину не перезавантажать, і збій залишається невідрізнюваним від закритого порту. Клієнти за NAT простіші: за публічної адреси сервера NAT-T на UDP 4500 їх несе, і це значення не задіяне.
Коли PPP піднято, MTU з чорною дірою імітує мертвий тунель: дрібні пакети проходять, рукостискання TLS або завантаження сторінки зависає, а клієнт може досі показувати «під'єднано». Знизьте MTU інтерфейсу або затисніть MSS на шлюзі, перш ніж звинувачувати сервер. Маршрутизація роздільного тунелю — інший самозванець; підмережа, надіслана з хибною маскою, лишає тунель здоровим, а один застосунок недоступним. Приватне ім'я хоста додає свій крок: якщо запит виходить через локальний розв'язувач, ім'я не розв'язується до перевірки будь-якого маршруту.
Контрольний список, перш ніж торкатися облікових даних
Пройдіть список по черзі й зупиніться на першому збійному пункті. Кожен крок дешевий, і кожен виключає цілий клас правок.
- Підтвердьте, що асоціація є на обох кінцях, зіставлена за автентичністю вузла, а не за міткою «під'єднано».
- Підтвердьте, що UDP 1701 доходить до xl2tpd; асоціація без виклику — це ваш збій.
- Прочитайте вердикт PPP і, якщо він автентифікував, результат IPCP, перш ніж вважати пароль хибним.
- Лише тепер уведіть облікові дані знову в форматі, якого чекає сервер, бо префікс домену змінює обліковий запис.
- Якщо все ще не працює, зніміть обидва кінці з вирівняними мітками часу й порівняйте етап за етапом.
Зупинка на другому кроці означає проблему шляху або інкапсуляції, і жодна правка пароля її не зрушить. Зупинка на третьому кроці означає, що журнал уже називає метод або пул адрес для виправлення. У будь-якому разі наступна зміна — та, яку ви можете обґрунтувати, і ви перестаєте крутити налаштування, що ніколи не брали участі.