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 там, де політика дозволяє. У будь-якому разі після зміни переконайтеся, що той самий проксі, пункт призначення й профіль досягають наступного етапу; браузер, який завантажує сторінку за цією адресою, використовує інший протокол і нічого не доводить про тунель.