TLS идёт внутри канала управления, а не по всему туннелю

Увидеть слово TLS в описании VPN и заключить, что веб-прокси поймёт этот трафик, — распространённое упрощение. Внутри этого протокола узлы обмениваются собственными пакетами, и TLS работает как часть одного канала в этом обмене. Полезная нагрузка, важная для пользователя, идёт в другом формате сообщений, поэтому эти две вещи никогда не совпадают с обычной сессией HTTPS.

Сначала идёт конверт

Каждый пакет туннеля начинается с собственного заголовка протокола: типа сообщения, идентификатора ключа и, при транспорте байтового потока, префикса длины, который отмечает, где пакет заканчивается. Читатель, который не разбирает этот конверт, не может знать, где начинается следующее поле.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Этот набросок — карта, а не таблица байтов, потому что точные поля зависят от типа сообщения, хотя первый октет всегда упаковывает код операции и идентификатор ключа вместе. Догадка о типе сообщения по номеру порта — это то, из-за чего декодеры в итоге неверно называют увиденное. Для диагностики важен порядок: транспорт, затем конверт протокола, затем один из двух видов работы. Прочитайте конверт, прежде чем составлять мнение о том, что следует дальше. Декодер, начинающий не с того места, выдаёт уверенную чушь.

Слой надёжности принадлежит протоколу

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

Преимущество в том, что рукопожатие TLS получает надёжный носитель даже тогда, когда внешний транспорт — UDP. Цена в том, что одна датаграмма может содержать лишь часть этого разговора, поэтому отношение к ней как к самостоятельной записи TLS даёт чушь. Пересборка должна происходить на уровне протокола. Поэтому захваченный пакет редко выглядит как полный шаг рукопожатия.

Переключение внешнего транспорта на TCP не убирает этот слой. Надёжный транспорт означает меньше повторных передач на уровне протокола, а не то, что кадрирование исчезает или трафик становится HTTP.

Пакеты данных используют другой формат

Когда сессия существует, полезная нагрузка приходит как сообщения данных, несущие внутренние пакеты IP или кадры Ethernet. Они защищены собственными ключами и собственной обработкой и не являются прикладными записями TLS ни в каком смысле, который приняла бы библиотека TLS.

Это разделение видно в конфигурации: канал управления и канал данных имеют отдельные настройки шифра, поэтому строка журнала, называющая один, ничего не говорит о другом. Читать сильный шифр управления как доказательство сильного шифра данных — распространённая ошибка в отчётах.

Держите и связанное заблуждение за пределами объяснения. TLS — это не канал с открытым ключом рядом с симметричным каналом данных, поскольку сам TLS защищает свои записи симметрично после установления ключей. Настоящее различие — роль и формат пакета, а не то, какую криптографию использует каждая сторона.

Почему прокси HTTPS не может помочь

Прокси, завершающий TLS, ожидает поток записей TLS, а затем прикладной протокол внутри него. Канал управления этого протокола переносится внутри собственного кадрирования со слоем надёжности вокруг, поэтому завершающий прокси читает это кадрирование как повреждённый ввод.

Прозрачный форвардер, который пропускает байты или датаграммы, не интерпретируя их, может работать при условии, что он не переписывает и не пересобирает поток. Вопрос, который нужно задать о любом посреднике, — передаёт ли он фактический транспорт и кадрирование, а не поддерживает ли он TLS где-то. Спросите это, прежде чем тратить вечер на правила прокси. Большинство сбоев здесь архитектурные, а не отсутствующая настройка.

Как правильно читать трассу

Ожидайте сначала обмен управления, затем гораздо большее число сообщений данных, причём оба делят один транспорт. Если фаза управления завершается, а фаза данных застревает, неисправность касается ключей, маршрутизации или фильтрации пути данных, а не рукопожатия. Захватите несколько сообщений данных и проверьте, покидают ли они клиента вообще. Это единственное наблюдение делит поиск пополам.

Исторические описания методов ключа в документации протокола не означают, что данный выпуск всё ещё поддерживает каждый старый формат. Проверьте версию, которую вы запускаете, прежде чем строить ожидание на абзаце, описывающем, как всё работало раньше.