د 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 اورېدونکی نه دی۔
هماغه تله هغو کسانو ته هم رسېږي چې د PPTP دورې پروفایلونه له زوړ iPad لارښودونو کاپي کوي۔ انتخابونه لا هم په انټرفیس کې شته؛ خو هغه خدمت چې شاته دی نور په دې پروتوکول نه خبرې کوي۔
پرېکړه چې کومه طبقه سمه کړو
له هر څه بدلولو مخکې وپوښتئ چې کومه طبقه ناکامه شوه۔ که کلینټ نشي کولی غونډه جوړه کړي، ستونزه په لېږد کې ده او پراکسي ساحه بې اړیکې ده۔ که ټانل ولاړ وي خو یو اپلیکیشن خپل سرور ته نه رسېږي، د اپلیکیشن پراکسي کتل ارزښت لري۔ که ټانل ولاړ وي او ټول اپلیکیشنونه ناکام شي، د ټانل په داخل کې لارښوونه او DNS شکمن دي۔
د لومړي حالت لپاره، له آپریټر وپوښتئ چې کوم منل شوی بدیل لېږد یا شبکه ملاتړ کوي۔ په TCP 443 باندې OpenVPN شته ځکه چې ځینې شبکې یوازې هماغه اجازه ورکوي، او لا هم غواړي چې سرور هغه واوري۔
بند شوی UDP پورټ د بدیهي حل اجازه مه ګڼئ۔ د دروازې سند یا هویت کتنې ژوندي وساتئ، پرځای د دې چې د لاس ورکولو د برابرولو لپاره یې بندې کړئ۔
دواړه طبقې یو یو تایید کړئ
لومړی ټانل تایید کړئ: د کلینټ په حالت پاڼه کې جوړه شوې غونډه او د صفر نه توپیر لرونکې بایټ شمېره وګورئ۔ بیا د پراکسي تنظیم په مستقیم ډول ولولئ, د اغېزمن ترتیباتو لپاره scutil --proxy یا د ساتل شوي ارزښت لپاره networksetup -getwebproxy Wi-Fi سره۔ بیا یو اپلیکیشن چې د سیسټم پراکسي درناوی کوي او یو چې له پامه غورځوي یې ازموئ، ځکه ډېر اصلي اپلیکیشنونه له پامه غورځوي یې۔
درې پایلې، درې جلا سمونونه۔
که دواړه طبقې بریالیتوب راپور کړي او اپلیکیشن بیا هم ناکام شي، نو ووېشل شوی ټانل، DNS او د اپلیکیشن خپل شبکه یي تنظیمات وګورئ۔ دا درېيمه طبقه ده، او هغه هم د پراکسي ساحه نه ده۔