Шта заправо ради поље Proxy у Apple VPN профилу
Попуњавање поља прокси не претвара VPN у HTTP. Укључене су две везе, а поље стиже само до једне од њих.
Попуњавање поља Proxy у Apple VPN конфигурацији ствара осећај да би требало да преусмери тунел кроз веб порт. Али не. Поље бира посредника на нивоу апликације за саобраћај који компатибилна апликација одлучи да пошаље тамо. А везу самог 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 и сопствена мрежна подешавања апликације. То је трећи слој, и ни он није поље проксија.