Спрямуйте 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 replyWhat it meansWhere to look next
407 Proxy Authentication RequiredThe proxy wants its own credentialsThe client's proxy auth options, not the VPN account
403 ForbiddenThe destination or method is not permittedThe proxy's access policy for that host and port
503 Service UnavailableThe proxy could not complete the upstream connectionThe 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 там, де політика дозволяє. У будь-якому разі після зміни переконайтеся, що той самий проксі, пункт призначення й профіль досягають наступного етапу; браузер, який завантажує сторінку за цією адресою, використовує інший протокол і нічого не доводить про тунель.

Схожі статті