Помогает ли TCP 443 на самом деле? Только если сервер слушает там
Профиль TCP — это запасной путь, а не маскировка. Проверьте, слушает ли сервер этот порт, и затем взвесьте цену двойного TCP против недоступности.
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Три условия решают, оправдает ли запасной путь свою цену
Первое условие — оператор вообще предлагает этот транспорт; без него всё остальное неважно. Второе — путь поддерживает долгоживущую сессию, так как некоторые сети сбрасывают соединения, остающиеся открытыми, вместо полной блокировки порта. Третье — является ли запасной путь намеренным исключением или обходным решением, скрывающим неисправность, которую вы не устранили.
У каждого условия есть дешёвая проверка. Отказ на любом из них с точки зрения клиента выглядит одинаково:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Прежде чем сравнивать транспорты, завершите любой вход на портале авторизации. Сеть, не допустившая ваше устройство, блокирует оба транспорта, и тогда сравнение измеряет портал, а не туннель. Войдите, убедитесь, что обычный просмотр работает, и только после этого начинайте тест.
Цена, которую вы принимаете: TCP внутри TCP
TCP повторно передаёт потерянные сегменты и сохраняет их порядок. Когда приложение, которое тоже использует TCP, работает внутри туннеля TCP, два уровня восстановления реагируют на одну и ту же потерю, и именно это взаимодействие делает туннель медленным на пути с потерями. Симптом — задержка и дрожание, а не чистая ошибка, что облегчает обвинение дальнего конца. Измеряйте со стороны клиента на обоих транспортах, прежде чем делать вывод.
UDP избегает этой вложенности, и это главная причина, по которой операторы предпочитают его и предлагают TCP только как альтернативу. Стабильное TCP-соединение всё равно полезнее недоступного UDP-соединения, поэтому сравнение идёт между двумя реальными издержками, а не между хорошим и плохим вариантом. Держите устройство и сеть доступа неизменными, пока сравниваете, иначе результат опишет не ту переменную.
Некоторые клиентские функции документированы только для одного транспорта, поэтому запасной профиль может тихо отбросить поведение, на которое вы полагались. Прочитайте требование опции к транспорту, прежде чем считать профиль TCP простой заменой.
Неисправности, которых другой транспорт не касается
Просроченный сертификат по-прежнему требует проверки часов или продления, а отклонённая учётная запись — правильных учётных данных. Сохраняйте проверки идентичности сервера, которые дал оператор, потому что знакомый номер порта никого не аутентифицирует. Порт, который отвечает, говорит лишь о том, что что-то слушает.
Если туннель поднимается, а назначения по-прежнему недоступны, оставшаяся проблема — маршрутизация или разрешение имён после соединения, а не транспорт. Идите этим путём вместо перебора портов, потому что именно так исчезает полдня. Профиль говорит, какой транспорт пробовать; он никогда не говорит, почему путь UDP не сработал.