Чи справді допомагає TCP 443? Лише якщо сервер слухає там

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

Номер порту — не обіцянка транспорту

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

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

Підтвердьте слухач, перш ніж чіпати профіль

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

Обидві сторони цього збігу видно в конфігурації, а параметри з'єднання проєкту OpenVPN документують обидві форми. Мінімальна пара виглядає так:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Три умови вирішують, чи виправдає запасний шлях свою ціну

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

Кожна умова має дешеву перевірку. Відмова на будь-якій із них з погляду клієнта виглядає однаково:

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

Ціна, яку ви приймаєте: TCP усередині TCP

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

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

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

Несправності, яких інший транспорт не торкається

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

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