MSCHAPv2 — це не протокол VPN: спершу запитайте про тунель

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

Автентифікація їде всередині тунелю

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

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

Три місця, де з'являється той самий метод

У PPP крок автентифікації чекає, поки з'явиться канал зв'язку, і RFC 2759 визначає MS-CHAPv2 як цей крок, тому метод з'являється в L2TP і в старіших розгортаннях PPTP. Тунель завершується першим, а переговори PPP відбуваються всередині нього, тож невдала стадія PPP може залишити в журналі сервера враження, ніби тунель установлено. Читайте ці дві стадії окремо, перш ніж робити висновок, що облікові дані відхилено. Отже, клієнт, налаштований для L2TP, може бути цілком правильним і все ж неправильним клієнтом для шлюзу, який говорить лише IKEv2.

IKEv2 натомість вміщує EAP-MSCHAPv2 усередину обміну ключами, тому ті самі облікові дані відмовляють в інший момент і виявляються як помилка автентифікації, а не як помилка сеансу. Профіль IKEv2 платформи Android — щоденний приклад, і він запитує сертифікат або ідентифікатор сервера замість параметрів PPP. Ім'я облікового запису однакове в обох схемах, тож воно не може сказати, який у вас. Це вирішує лише список підтримуваних протоколів в оператора.

VPN на основі TLS додає третю схему, зі своїми полями імені користувача й пароля та без MS-CHAPv2 будь-де в обміні. Тому вигляд поля пароля не є доказом протоколу за ним, адже форму збудовано так, щоб вона виглядала знайомо. Підтвердьте протокол із документації сервера, а не з форми вікна клієнта.

Відповіді, які вам справді потрібні

Надішліть запит списком, бо на список важко відповісти наполовину. Попросіть протокол тунелю, метод усередині нього й клієнт, який оператор підтримує на вашій платформі. Далі попросіть ідентичність і налаштування довіри шлюзу, формат облікового запису та те, що має бути доступним після підняття з'єднання.

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

Не послаблюйте перевірку шлюзу

Сервер також доводить свою ідентичність клієнтові, і ця половина обміну не є оздобою. Вимкнення перевірки сертифіката, щоб упиратий профіль підключився, приймає будь-яку кінцеву точку, що відповідає, включно з тією, куди ніхто не збирався потрапити. Воно також приховує справжню невідповідність замість того, щоб її вирішити, що зсуває збій на пізніший і менш очевидний момент. Профіль, якому потрібна вимкнена перевірка, вказує на те, що він не може перевірити.

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

Підберіть профіль, потім доведіть кожен етап

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

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