OpenVPN через HTTP-прокси: сначала прочитайте ответ CONNECT
CONNECT-прокси пересылает байты, поэтому обеим сторонам нужен TCP. Прочитайте 407, 403 и 503, прежде чем винить сертификаты, и оставьте проверку сервера включённой.
Направьте VPN-клиент на корпоративный HTTP-прокси, и первый полезный факт: прокси не говорит на протоколе VPN. Он открывает обычное TCP-соединение по указанному адресу, а затем отходит в сторону, оставляя клиенту и серверу вести собственный обмен через этот поток. Всё, что нужно клиенту — от типа транспорта до слушателя сервера — должно соответствовать этой схеме. Два несоответствия объясняют большинство отказов: UDP-профиль, нацеленный на CONNECT-прокси, и ответ прокси, ошибочно принятый за ошибку VPN.
Что прокси переносит, а что нет
Прокси — это всего лишь этап транспорта. Он не становится прокси браузера, не кеширует сайты, которые вы посещаете через туннель, и не видит внутренний трафик, если кто-то намеренно не настроил инспекцию. Туннель, который он открывает, по замыслу непрозрачен для него.
Это также означает, что прокси не может починить сервер без подходящего слушателя. Разрешение добраться до пункта назначения и служба, слушающая на этом пункте, — два отдельных факта, и только первый относится к администратору прокси.
Транспорт должен быть TCP на обоих концах
Обычный CONNECT-прокси передаёт только поток байтов , поэтому клиент должен использовать потоковый транспорт. Фрагмент клиента для такого случая выглядит так:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Стороне сервера нужен настоящий TCP-слушатель на порту, указанном в строке remote. Замена proto udp на proto tcp-client в профиле создаёт клиента, ожидающего поток; сам поток на другой стороне не создаётся. Если тот же сервер отвечает на этом порту ещё и по UDP, это другой слушатель, а не второй режим того же.
Там, где существует отдельный экземпляр TCP, его туннельное устройство, пул адресов и маршрутизация — собственные ресурсы. Копирование рабочей конфигурации и правка слова транспорта оставляет эти ресурсы указывающими на исходный экземпляр, что даёт соединение, которое проходит аутентификацию и затем ничего не маршрутизирует.
Прочитайте ответ прокси раньше результата VPN
Первый обмен клиента — строка запроса с именем хоста и порта назначения. Ответ на эту строку говорит, существует ли вообще поток байтов, и приходит раньше, чем проверяется любой сертификат или учётные данные:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
Ответ класса 200 на CONNECT означает, что поток существует. Он ничего не говорит о том, доверенный ли сертификат шлюза, совпадает ли общий ключ и действительна ли учётная запись пользователя. Эти проверки происходят позже, внутри потока, и завершаются неудачей с собственными сообщениями клиента, а не со строкой состояния HTTP. Ищите в журнале клиента первое OpenVPN событие после рукопожатия с прокси, а не последнюю строку перед закрытием окна.
Учётные данные прокси и учётные данные VPN часто являются разными идентичностями в руках разных команд. 407 — это не неверный пароль учётной записи VPN, а отклонённый сертификат — не проблема прав прокси.
Что CONNECT не раскрывает
Явный туннель CONNECT — это не перехват. Прокси пересылает байты и не завершает TLS-сеанс VPN, поэтому проверка сертификата сервера клиентом остаётся осмысленной и должна быть включена. Отключение проверки, чтобы пройти прокси, решает другую задачу, не вашу.
Существуют отдельные схемы, где организация намеренно завершает и инспектирует TLS. Они требуют собственной конфигурации доверия и собственного решения о политике, и это не то, что просит обычная строка http-proxy.
Цена TCP внутри TCP
Перенос туннеля по TCP сохраняет внешний поток упорядоченным и с повторной передачей, а внутренний трафик обычно тоже TCP. Два механизма восстановления не согласуются, поэтому один потерянный сегмент может остановить всё, что делит этот внешний поток, пока он не будет передан повторно. Это настоящий компромисс ради совместимости, а не бесплатное улучшение.
Используйте путь через прокси, когда сеть не оставляет альтернативы, и предпочитайте прямой путь UDP там, где политика позволяет. В любом случае после изменения убедитесь, что тот же прокси, пункт назначения и профиль достигают следующего этапа; браузер, загружающий страницу по этому адресу, использует другой протокол и ничего не доказывает о туннеле.