SSTP спочатку автентифікує сервер, а потім користувача

Клієнт SSTP може завершити TLS і все одно через секунду відхилити користувача. Ця послідовність не помилка, а стек протоколів: спочатку безпека транспорту, потім автентифікація користувача. Оскільки два етапи зазнають невдачі з різними повідомленнями, їм потрібні й різні виправлення. Прочитати, на якому етапі виникла помилка, — це більша частина діагностики.

Довірений сертифікат доводить кінцеву точку; про обліковий запис він не каже нічого.

Що встановлює рукостискання TLS

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

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

Що додають SSTP і PPP

SSTP працює поверх HTTPS і несе всередині PPP, зі своїм обміном керування навколо з'єднання. Потім PPP виконує свої етапи з'єднання та автентифікації, а метод автентифікації залежить від політики сервера й можливостей клієнта. PAP, CHAP, MS-CHAPv2 і EAP — усі це варіанти автентифікації PPP з дуже різними властивостями. Перевірка користувача у VPN — це саме той етап PPP, а не шар TLS під ним.

Тому відмова користувачу може означати облікові дані, обмеження облікового запису або невідповідність методу.

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

Зіставте помилку з етапом

Перевірте, чи з'єднання доходить до TLS, потім до обміну HTTP SSTP, потім до етапу PPP. Тримайте позначки часу в журналах вирівняними між спробами, щоб попередній збій не плутали з пізнішим успіхом. Клієнт, який записує дві спроби в одному вікні, інакше виглядатиме так, ніби він зазнав невдачі на останньому досягнутому етапі. Читайте першу значущу помилку, а не останній рядок.

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

Після входу авторизація все ще окрема

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

Це та сама шаруватість, яку показало рукостискання, на рівень вище.

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