Що насправді робить поле Proxy у профілі VPN на Apple
Заповнення поля проксі не перетворює VPN на HTTP. Задіяні два з'єднання, і поле досягає лише одного з них.
Заповнення поля Proxy у конфігурації VPN на Apple створює відчуття, ніби воно має перенаправити тунель через веб-порт. Але ні. Поле вибирає посередника на рівні програми для трафіку, який сумісна програма вирішить туди надіслати. А з'єднання самого VPN-клієнта зі шлюзом визначають протокол, слухач і транспорт, які ви налаштували, і це окремі рішення.
Два з'єднання, два власники
Будь-яке таке налаштування включає з'єднання від клієнта до шлюзу та з'єднання від програми до призначення. Розділ Proxy говорить про друге, хоча воно в тому самому профілі, що й перше.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Довідник налаштувань проксі від Apple перелічує HTTP, HTTPS, SOCKS і автоматичну конфігурацію проксі, що описує варіанти проксі для програм. Жоден із цих записів не каже, як пакет IPsec або WireGuard досягає шлюзу.
Ось швидка перевірка, яка все вирішує. Назвіть порт і протокол, які VPN-клієнт повідомляє у своєму журналі. Якщо цей рядок досі каже UDP 500 або UDP 51820, поле проксі нічого в ньому не змінило.
Коли поле — правильний інструмент
Є реальний випадок, коли проксі стоїть перед тунелем, але це функція клієнта, а не поле профілю. Посібник OpenVPN документує --http-proxy для TCP-з'єднань, що передаються через проксі HTTP CONNECT. Для використання потрібні відповідна опція клієнта, шлюз, доступний у такий спосіб, і проксі, який дозволяє CONNECT на використовуваний порт.
Якщо ваш клієнт надає цю опцію і мережа дозволяє CONNECT на порт, це може працювати. Якщо клієнт її не надає, заповнення системного проксі взагалі не впливає на тунель.
Коли це нічого не змінює
Профіль IKEv2 або IPsec не стає HTTP-тунелем через те, що поле проксі заповнене. WireGuard теж, адже формат його конфігурації не знає поняття проксі. Зміна порту шлюзу також не змінює його протокол. А кінцева точка, що відповідає на звичайний HTTPS, не стає автоматично слухачем VPN.
Та сама пастка ловить тих, хто копіює профілі епохи PPTP зі старих посібників для iPad. Опції все ще є в інтерфейсі; служба за ними більше не говорить цим протоколом.
Вирішити, який рівень виправляти
Запитайте, який рівень відмовив, перш ніж щось змінювати. Якщо клієнт не може встановити сеанс, проблема в транспорті, і поле проксі тут ні до чого. Якщо тунель піднятий, але одна програма не досягає свого сервера, варто перевірити проксі програми. Якщо тунель піднятий і всі програми зазнають невдачі, підозрювані — маршрутизація та DNS усередині тунелю.
Для першого випадку запитайте в оператора, який затверджений альтернативний транспорт або мережу він підтримує. OpenVPN через TCP 443 існує тому, що деякі мережі дозволяють лише це, і він досі вимагає, щоб сервер його слухав.
Не вважайте заблокований порт UDP дозволом на імпровізацію. Зберігайте перевірки сертифіката або ідентичності шлюзу непошкодженими, а не вимикайте їх, щоб рукостискання підійшло.
Підтвердіть обидва рівні по черзі
Спочатку підтвердьте тунель: перевірте на сторінці стану клієнта встановлений сеанс і ненульовий лік байтів. Потім прочитайте налаштування проксі безпосередньо, з scutil --proxy для чинної конфігурації або networksetup -getwebproxy Wi-Fi для збереженого значення. Далі перевірте одну програму, яка поважає системний проксі, і одну, яка його ігнорує, бо багато рідних програм його ігнорують.
Три результати, три різні виправлення.
Якщо обидва рівні повідомляють про успіх, а програма все ще не працює, подивіться на роздільне тунелювання, DNS і власні мережеві налаштування програми. Це третій рівень, і він теж не поле проксі.