Какво всъщност прави полето 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 и собствените мрежови настройки на приложението. Това е трети слой и той също не е полето за прокси.