Тайм-аут SSTP або помилка сертифіката: як їх розрізнити

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

Два збої, два різні обміни

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

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

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

Тайм-аут означає, що етап так і не завершився

Почніть із розв'язання імен і доступності TCP, бо тайм-аут там виглядає так само, як тайм-аут пізніше. Перевірка порту, яка повідомляє, що 443 відкритий, доводить лише те, що слухач прийняв з'єднання, і нічого більше.

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

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

Помилка сертифіката означає, що ідентичність було відхилено

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Зберігайте успішний етап TLS незмінним, коли його пройдено, бо пізніше скасування приховує, яка зміна справді виправила тунель.

Де ці два плутаються

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

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

Питання сертифіката й питання доступності задокументовані окремо не випадково.

Повторіть перевірку справжнім клієнтом, потім ідіть усередину

Коли конкретне виправлення на місці, повторіть спробу справжнім клієнтом SSTP і реальним профілем, а не вкладкою браузера.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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