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ке жана колдонмонун өзүнүн тармактык жөндөөлөрүнө көрүңүз. Бул үчүнчү катмар, жана ал да прокси талаасы эмес.