OpenVPN на 443 досі заблоковано? Перевірте, що інспектує мережа
Порт 443 змінює номер, а не форму протоколу. Якщо шлях інспектує або завершує TLS, наступні тести — обгортка та правильний маршрут до хоста.
Тунель підключається з домашньої лінії і застрягає в готельній або офісній мережі, а перенесення сервера на порт 443 нічого не змінило. Цей результат досить частий, щоб мати форму: порт був легкою частиною, а решта рішення належить усьому, що стоїть між клієнтом і сервером. Два питання вирішують більшість випадків, і жодне з них не про шифри. Чи приймає мережа рукостискання TLS на цю адресу, і чи зберігає клієнт маршрут до власної обгортки, поки тунель піднятий?
Рукостискання видає більше за номер
Рідний слухач VPN на TCP 443 говорить своїм протоколом з першого пакета. У ClientHello є поле версії, випадкове значення і список розширень, і пристрій, що прочитав кілька сотень байтів, бачить різницю, нічого не розшифровуючи. Номери портів дешево задовольнити, а форма протоколу — це те, що фільтр справді перевіряє. Правила зазвичай пишуть і за протоколами, тому політика, що інспектує TLS, нічого не каже про UDP.
Прозорий проксі, який вимагає дійсного сеансу TLS, скидає з’єднання під час налаштування, часто після завершення рукостискання TCP. Ця деталь важлива пізніше, бо означає, що журнал клієнта обривається після встановлення сокета.
Обгортання потоку створює дві точки відмови
Обгортка TLS на кшталт stunnel відновлює очікувану форму: клієнт підключається до локального слухача, обгортка відкриває справжній сеанс TLS до сервера на 443, а друга обгортка на сервері передає розшифровані байти демону VPN. Зовнішній сеанс тепер виглядає як будь-яке інше з’єднання HTTPS. Демон VPN на сервері має слухати лише на loopback, бо нічому поза обгорткою не треба до нього діставатися.
Для цієї схеми мають збігтися три окремі речі. Профіль клієнта вказує на локальний слухач, сертифікат сервера відповідає імені, яке перевіряє клієнт, а переадресація на боці сервера націлена на порт, який демон справді використовує. Помилитеся в будь-якій із них — і з’єднання вмирає, не дійшовши до рівня VPN. Тоді невідповідність сертифіката проявляється як помилка обгортки, а не як помилка VPN, і тому обидва журнали варто читати поряд.
Маршрут до обгортки — це пастка
Щойно тунель піднімається, маршрут за замовчуванням вказує в нього, і зовнішньому сеансу TLS потрібен шлях, який не входить у тунель, що він несе. Звичайний клієнт VPN захищає адресу, на яку дзвонить; обгорнутий клієнт дзвонить на власний loopback, тому адреса призначення обгортки невидима для цього захисту.
sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20
Точні адреси вписуєте ви, і маршрут має існувати протягом усього життя з’єднання, а не лише під час запуску. Невеликий скрипт-обгортка, який додає маршрут до клієнта й видаляє після, надійніший за запам’ятовану команду.
В Android еквівалент цього винятку — налаштування для кожного застосунку: виключіть застосунок-обгортку з тунелю, щоб його власний трафік виходив через мобільне з’єднання. Без виключення обгортка спрямовується в той тунель, який намагається побудувати, і цикл перепідключення виглядає як проблема сервера.
Прочитайте таймінги, перш ніж щось змінювати
Сеанс, який помирає через однаковий інтервал щоразу, — це підпис політики, а не криптографічний збій, і довгі ліміти потоку дають саме такий візерунок. З’єднання, яке скидається одразу після рукостискання, вказує на проксі, якому не сподобався ланцюжок сертифікатів.
Порівняйте видавця сертифіката звичайного сайту HTTPS з обох мереж. Якщо в обмеженій мережі видавець інший, щось завершує TLS посередині, і жодна обгортка не переживе цього перехоплення без змін. Те саме порівняння підкаже, чи блокування націлене на ім’я вашого сервера, чи на кожен сеанс TLS на цій адресі.
Запишіть спостережувану поведінку: скільки тривав сеанс, чи відкрився сокет, чи зафіксувала обгортка рукостискання. Кожен із цих пунктів звужує наступний тест.
Перевіряйте одну змінну за раз
Спершу перевірте UDP, бо деякі мережі повністю його відкидають, а збій UDP нічого не каже про 443. Потім спробуйте TCP 443 без обгортки, далі обгортку на 443. Читайте журнал клієнта на кожному кроці й зупиніться, щойно поведінка зміниться.
Змінюйте по одному елементу за спробу. Новий порт, нова обгортка і новий шифр в одному прогоні не дадуть вам сказати, що з трьох мало значення.