Што насамрэч робіць поле 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 і ўласныя сеткавыя наладкі праграмы. Гэта трэці ўзровень, і ён таксама не поле проксі.