SSTP проти OpenVPN: той самий порт 443, інший протокол

Обидва варіанти можуть стояти за TCP 443, тому люди вважають їх взаємозамінними кінцевими точками. Це не так: SSTP сервер говорить PPP усередині HTTPS, тоді як сервер OpenVPN говорить власним протоколом поверх TLS або через необроблений потік UDP. Спрямування одного клієнта на порт іншого дає з'єднання, яке ніколи не досягає запрошення на вхід. Вибір стосується того, який клієнт і який транспорт ви можете підтримати, а не номера.

Спільний порт не робить спільного протоколу

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

Ані перейменований профіль, ані інший пункт меню не перетворюють одне на інше. З'єднання SSTP створюється в налаштуваннях VPN Windows з адресою сервера й даними автентифікації оператора, тоді як з'єднанню OpenVPN потрібні клієнт і відповідний файл конфігурації. Специфікація SSTP від Microsoft описує перше і не описує рукостискання OpenVPN.

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

SSTP тунелює PPP усередині HTTPS

Назва описує конструкцію: кадри PPP, що переносяться в сеансі HTTPS, тобто TLS знизу й сертифікат, який клієнт може перевірити. Windows включає це як вбудований тип VPN, тому керований ноутбук часто може підключитися без додаткового програмного забезпечення, крім профілю від оператора.

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

SSTP зазвичай лише TCP. Цей єдиний транспорт впливає на поведінку на лінії з втратами, бо повторне передавання відбувається і всередині тунелю, і під ним.

OpenVPN приносить власний клієнт і вибір транспорту

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

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

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

Виберіть за клієнтом, транспортом і підтримкою

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

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

Потім підтвердьте, яке саме ви встановили, перш ніж налагоджувати будь-що інше:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

У керованому парку поширення профілів і підтримка оновлень зазвичай вирішують питання задовго до будь-якого вимірювання транспорту.