Назвати продукт VPN-клієнтом ще не означає, що він розмовляє SSTP, а порт 443 в адресі доводить ще менше. SSTP запускає TLS поверх TCP 443, далі обмін керування SSTP, далі PPP для самого з'єднання, а зверху — перевірку сертифіката й метод автентифікації PPP. Клієнт підтримує протокол лише тоді, коли зазначена реалізація в інстальованій версії проходить кожен із цих рівнів згідно з вимогами вашого сервера. Виконуйте наведені нижче перевірки по порядку й зупиняйтеся на першій невдалій, бо саме її варто вирішувати.

Зіставте реалізацію, версію та платформу

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

У Windows тип тунелю походить із платформи, а не з графічного інтерфейсу, тому питайте платформу. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress показує Sstp, коли вбудований клієнт спробує протокол, а довідник типів з'єднань перелічує його серед вбудованих типів тунелю. У Linux вбудованого клієнта SSTP немає взагалі, тому питання зводиться до того, чи встановлена й актуальна окрема реалізація, наприклад sstpc з пакета sstp-client.

Спочатку формат профілю, потім етикетка

Профілі не взаємозамінні, і переданий вам файл зазвичай вирішує питання швидше за будь-який перелік можливостей. Директиви OpenVPN, ключі WireGuard і параметри з'єднання SSTP описують три не пов'язані протоколи, і жодне вікно імпорту не перетворює одне на інше. Спільний порт TCP 443 нічого не перекладає, бо SSTP, OpenVPN через TLS і звичайна служба HTTPS можуть займати той самий порт і не мати нічого спільного над ним.

Якщо файл — це .ovpn або конфігурація WireGuard, відповідь уже на столі: від цього клієнта не вимагають розмовляти SSTP. Імпорт у клієнт, що вміє лише SSTP, зазнає невдачі вже на етапі профілю, задовго до початку будь-яких переговорів про протокол.

Що TLS не доводить про розгортання

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

Далі підтвердьте метод автентифікації PPP, бо розгортання з EAP-TLS потребує клієнта, здатного пред'явити сертифікат усередині PPP, тоді як метод на основі пароля потребує підтримки такого обміну. Адреса сервера й пароль не описують реальної вимоги організації, особливо коли попереду стоїть другий фактор або перевірка пристрою. Запитайте, який метод вимагає сервер, перш ніж припускати, що клієнт його задовольнить.

Простежте сеанс через чотири етапи

Дивіться, як з'єднання проходить чотири межі: TCP і TLS до сервера, обмін керування SSTP, узгодження PPP, а потім ресурс, який вам справді потрібен. Журнал, що обривається після TLS, описує іншу несправність, ніж той, що обривається всередині PPP, і ці два ведуть до різних відповідальних. Завантаження браузером вебсторінки хоста доводить лише те, що на 443 щось відповіло, а це найчастіший хибний позитив у цій галузі. Якщо сторінка завантажується, а клієнт досі не працює, проблема вище TLS і вебсервер не підозрюваний.

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

Коли підтримки немає, змініть план

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

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

Схожі статті