Apple VPN профиліндегі Proxy өрісі шын мәнінде не істейді
Прокси өрісін толтыру VPN-ды HTTP-ге айналдырмайды. Екі байланыс қатысады, ал өріс тек біреуіне жетеді.
Apple VPN конфигурациясындағы Proxy өрісін толтыру туннельді веб-порт арқылы бағыттайтын сияқты сезіледі. Бірақ олай емес. Өріс үйлесімді қолданба сол жаққа жіберуді шешетін трафик үшін қолданба деңгейіндегі делдалды таңдайды. Ал 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 CONNECT проксиі арқылы тасымалданатын TCP байланыстары үшін --http-proxy параметрін құжаттайды. Оны пайдалану үшін сәйкес клиент опциясы, осылай жетуге болатын шлюз және пайдаланылып отырған портқа CONNECT рұқсат ететін прокси қажет.
Клиентіңіз бұл опцияны ұсынса және желі портқа CONNECT рұқсат етсе, ол жұмыс істеуі мүмкін. Клиент оны ұсынбаса, жүйелік проксиді толтыру туннельге еш әсер етпейді.
Қашан ештеңені өзгертпейді
IKEv2 немесе IPsec профилі прокси өрісі толтырылғандықтан HTTP туннеліне айналмайды. WireGuard та емес, оның конфигурация пішімінде прокси ұғымы жоқ. Шлюз портын өзгерту оның протоколын да өзгертпейді. Ал қарапайым HTTPS-ке жауап беретін соңғы нүкте автоматты түрде VPN тыңдаушысы емес.
Сол тұзақ ескі iPad нұсқаулықтарынан PPTP дәуіріндегі профильдерді көшіретіндерді де ұстайды. Опциялар интерфейсте әлі бар; олардың артындағы қызмет енді бұл протоколда сөйлеспейді.
Қай қабатты түзетуді шешу
Бірдеңені өзгертуден бұрын қай қабаттың құлағанын сұраңыз. Клиент сессия орната алмаса, мәселе транспортта, ал прокси өрісінің қатысы жоқ. Туннель жұмыс істеп тұрса да бір қолданба өз серверіне жете алмаса, қолданба проксиін қараған жөн. Туннель жұмыс істеп, барлық қолданба құласа, күдіктілер — туннель ішіндегі маршруттау және DNS.
Бірінші жағдай үшін оператордан қай бекітілген балама транспорт немесе желіні қолдайтынын сұраңыз. TCP 443 үстіндегі OpenVPN кейбір желілер тек соған рұқсат беретіндіктен бар, және ол әлі де сервердің оны тыңдауын талап етеді.
Бұғатталған UDP портын импровизацияға рұқсат деп қабылдамаңыз. Қол алысуды сәйкестендіру үшін шлюздің сертификат немесе сәйкестік тексерулерін өшірудің орнына оларды бүлінбеген күйде ұстаңыз.
Екі қабатты бір-бірлеп растаңыз
Алдымен туннельді растаңыз: клиенттің күй бетінде орнатылған сессия мен нөлге тең емес байт санын қараңыз. Содан кейін прокси параметрін тікелей оқыңыз, тиімді конфигурация үшін scutil --proxy немесе сақталған мән үшін networksetup -getwebproxy Wi-Fi қолданып. Сосын жүйелік проксиді құрметтейтін бір қолданбаны және оны елемейтін бір қолданбаны сынап көріңіз, өйткені көптеген жергілікті қолданбалар оны елемейді.
Үш нәтиже, үш түрлі түзету.
Егер екі қабат та сәттілік туралы хабарласа да қолданба әлі құласа, бөлінген туннельдеуге, DNS-ке және қолданбаның өз желілік параметрлеріне қараңыз. Бұл үшінші қабат, және ол да прокси өрісі емес.