Чому PPTP і L2TP/IPsec зупиняються до запиту імені користувача?
Відсутність запиту імені користувача означає, що PPP так і не запустився, тому збій у транспорті, обміні ключами або налаштуванні тунелю. Перевірте порядок етапів, перш ніж перевстановлювати.
Відсутність запиту імені користувача — діагностичний подарунок: PPP ще не запустився, тому обліковий запис, пароль і доменна політика ще не запитувалися. У з'єднанні PPTP або L2TP/IPsec клієнт запитує облікові дані лише після того, як тунель існує і сервер почав сеанс PPP. Усе, що може відмовити до цього моменту, — це транспорт, обмін ключами або налаштування тунелю, а це значно менша ділянка, ніж «VPN зламано».
Відсутній запит звужує збій до трьох етапів
Запишіть останній етап, який видимо вдався, бо кожен має іншого власника й інше рішення. Вгадувати налаштування облікового запису, застрягши на два етапи раніше, — це спосіб втратити півдня.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Клієнт, який завершується за тайм-аутом без запиту, так і не отримав асоціацію IPsec, тому збій у IKE або в тому, чи доходять ваші пакети до шлюзу взагалі. Той, що повідомляє про перевірку облікових даних і потім падає, просунувся далі, ніж припускає повідомлення. Запит, за яким іде відмова, — це автентифікація PPP, і її місце в статті про обліковий запис, а не в цій.
Перший етап: протокол, який міжмережевий екран тихо відкидає
PPTP потребує TCP 1723 для каналу керування й протоколу IP 47 для шляху даних, і ці двоє подорожують окремо. Багато мереж пропускають 1723 і відкидають протокол 47, що дає тунель, який домовляється і потім не переносить нічого. Маршрутизатору з NAT також потрібен прохід із підтримкою GRE, а шлях доступу лише через IPv6 не може нести PPTP за жодної конфігурації.
L2TP поверх IPsec витрачає порт 500 на IKE і порт 4500 на обхід NAT, потім загортає сам трафік L2TP у 1701, а ESP несе захищене навантаження, щойно асоціація існує. Дозвольте два керуючі порти, але не ESP, і ви отримаєте точно той симптом із заголовка: видимий прогрес, потім мертвий клієнт до будь-якого діалогу облікових даних. Перевірка з точки доступу телефона — дешевий спосіб відокремити проблему клієнта від проблеми шляху.
Другий етап: ключ, який не ключ, пропозиція, яку не пропонують
Незбіжний попередньо спільний ключ відмовляє швидко й тихо, а звичайний варіант — ключ, який виглядає правильним на екрані, але несе вставлений перенос рядка або пробіл у кінці. На клієнті Linux діалог не обов'язково є джерелом істини: плагін L2TP у NetworkManager тримає секрети у файлах під /etc/ipsec.d/, і старіший файл для окремого з'єднання, який /etc/ipsec.secrets досі включає, буде використано замість щойно введеного. Скопіюйте цей файл у безпечне місце, приберіть його зі шляху включення, а потім введіть ключ заново вручну.
Друга половина цього етапу — пропозиція. Обидві сторони мають домовитися про той самий набір алгоритмів фази 1 — шифрування, цілісність і групу Diffie-Hellman — і про відповідні перетворення ESP для фази 2, інакше асоціація не утворюється взагалі. Шлюз, який пропонує лише 3DES, SHA1 і MODP1024, відмовить клієнту, налаштованому на сильніші алгоритми, і його журнал назве відкинуте перетворення. Журнал назве невідповідність, якщо ви прочитаєте його, а не перезапустите службу знову. Замість копіювання рядка алгоритмів із теми форуму запитайте шлюз, про які перетворення він справді домовлятиметься: ike-scan, спрямований на його адресу, повертає перетворення, про які він домовлятиметься. Якщо єдина пропозиція — криптографія, яку ваша політика більше не допускає, виправлення належить шлюзу, а не зниженню клієнта.
У Windows ключ і метод автентифікації живуть у профілі VPN, і невідповідність виявляється до запиту облікових даних, а не після. Там, де отримувач — Windows Server, переконайтеся, що роль віддаленого доступу встановлена, сертифікат відповідає імені, до якого підключаються клієнти, і жоден фільтр портів не є вужчим за перелічені вище протоколи.
Третій етап: тунель є, а PPP не запускається
Коли IKE завершено, а запит так і не з'являється, дивіться на демон тунелю, а не на міжмережевий екран. L2TP потребує чогось, що слухає на UDP 1701 — xl2tpd або kl2tpd у Linux, служба віддаленого доступу в Windows — а встановлена, але зупинена служба з боку клієнта виглядає точно як відкинутий пакет. Перевірте слухача, перш ніж знову відкривати правила, які ви вже перевірили. Далі PPP має домовитися, і перший обмін LCP — це місце, куди зазвичай сідає тиха відмова.
Одна пастка на цьому етапі зовсім не мережевий збій: Windows дозволяє лише одне з'єднання заданого типу VPN одночасно, тому друга спроба повертає помилку 937, «інше з'єднання цього типу використовується». Це локальне правило, і обійти його можна іншим пристроєм, іншим типом тунелю або спільним використанням єдиного наявного з'єднання.
Читайте журнал у порядку етапів, а не вгадуйте
Зупиніть клієнт, запустіть його знову і читайте компоненти в тому порядку, у якому вони пишуть журнал. Тобто спершу демон IPsec — strongSwan або Libreswan, і ipsec --version скаже який — потім демон L2TP, потім pppd. Який би компонент не писав останнім перед збоєм, він позначає етап для розслідування, бо все, що йде після нього в послідовності, взагалі не працювало.
Перевіряйте свіжим з'єднанням, а не збереженим сеансом, бо клієнт, що перепідключається з кешу, може пропустити частини обміну й відтворити застарілий результат. Підтвердіть доступність, обмін ключами, тунель і PPP по одному, у цьому порядку. Тоді відсутній запит перестає бути загадкою і стає другим рядком списку, за яким справді можна працювати. Цей же список ви передаєте мережевій команді, у якої інакше попросили б перевірити міжмережевий екран через збій, що живе в незапущеному демоні.