د iOS VPN پروفایل: passwordReference، نه پټنوم

تاسې یو پروفایل نصب کوئ، تونل پورته راځي او هر څه بشپړ ښکاري. بیا تلیفون بیا پیلېږي، on-demand پرته له کوم اپلیکیشن په مخکیني پلان کې اړیکه ویښوي، او تونل له پیل کولو انکار کوي. پروفایل لا هم هغه ځای دی او پټنوم لا هم سم دی، له همدې امله دا ناکامي خلک په غلط ځای کې لټون ته لېږي. Network Extension ستاسو راز له پروفایل څخه نه شي لوستلی: هغه ته د کیلي زنځیر داسې حواله پکار ده چې پخپله یې حل کړای شي.

لاندې لارښود له هغې غوښتنې څخه چې حواله جوړوي تر هغه بیا پیل پورې چې هغه ازموي، په دې سپارلو کې د یوې اړیکې هڅه تعقیبوي.

پروفایل لاستی ساتي، نه راز

NEVPNProtocol له یو دلیل پرته passwordReference او sharedSecretReference نه ښکاره کوي. کله چې ډیمون تونل پیل کړي، کېدای شي ستاسو په پروسه کې نه وي روان، نو ستاسو کوډ نه شي رابللی او پټنوم نه شي غوښتلی. هغه د کیلي زنځیر یوه تلپاتې حواله لولي، په خپل چوکاټ کې یې حل کوي، او توکی پخپله راوړي.

تاسې هغه حواله د کیلي زنځیر څخه په غوښتنې جوړوئ، چې له ډاټا غوښتنې جلا غوښتنه ده:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

بېرته راغلی شی پروتوکول ته ورکړئ، نه د توکي ډاټا. په عمل کې پروفایل ثبتوي چې راز چېرته اوسیږي، له همدې امله د ترتیباتو بیک اپ پټنوم په خاموشۍ plist ته نه کاپي کوي.

ولې API -50 ځواب ورکوي

errSecParam مانا دا ده چې غوښتنه یا ارزښت د دې عملیات لپاره خراب جوړ شوی و، او دا هغه تېروتنه ده چې ډېری وخت هغه مهال لیدل کېږي چې د حوالې او ډاټا غوښتنې ګډې شي. کله چې ترلاسه کوونکی کوډ د حوالې انتظار کوي، ډاټا غوښتل، passwordReference ته خام بایټونه ورکول، یا د داسې لاسرسي ګروپ سره پوښتنه کول چې اپلیکیشن یې نه شي کارولی، ټول هغه رامنځته کوي.

پوښونکي کتابتونونه دې ته بلنه ورکوي. هغه مرستندوی چې بایټونه بېرته ورکوي د هغه سره د بدلېدو وړ نه دی چې حواله بېرته ورکوي، نو سمون معمولاً بله پټنوم نه، بله پوښتنه ده.

همدا ناسم والی هغه پروفایل تشریح کوي چې پرته له شکایت خوندي کېږي او بیا نه نښلوي: خوندي شوی blob دی، نه لاستی، او ډیمون هیڅ د حل کولو نه لري.

ښه خوندي کېږي، د نښلولو پر مهال ناکامېږي

خوندي کول ستاسو د اپلیکیشن چوکاټ تمرینوي. نښلول د ډیمون چوکاټ، او دواړو لاسرسی یو شان نه دی. له همدې امله پروفایل کولای شي په سیمولیټر کې ټولې ازموینې تېرې کړي او په لومړي on-demand پیل کې ناکام شي.

د بیا پیل د نښې بڼه هم همدا ده: تر هغه پورې کار کوي چې اپلیکیشن خلاص وي او هغه مهال مري چې سیستم پخپله تونل پیل کړي.

له لېږلو دمخه د شالید لاره په قصد وازموئ. اپلیکیشن بند وي او on-demand اړیکه رامنځته کړئ، بیا د اپلیکیشن لاګ نه بلکې د وسیلې کنسول ولولئ، ځکه ناکامي هغه پروسه ثبتوي چې حواله یې د حل کولو هڅه کړې. که کنسول ښکاره کړي چې ډیمون توکی ردوي، حواله سمه ده او ستونزه د توکي د لاسرسي وړتیا ده.

بیا پیل به کار وکړي که نه، دا د لاسرسي وړتیا معلوموي

توکی باید د هر هغه سیسټمي پروسې لپاره لوستل کېدونکی وي چې تونل پیلوي، او دا له اپلیکیشن څخه چې په مخکیني پلان کې وي پراخه لیدونکي دي. همدا محدودیت ستاسو لپاره د لاسرسي وړتیا ځانګړنه ټاکي. هغه توکی چې تر لومړني خلاصېدو پورې خوندي وي د وسیلې له یو ځل خلاصېدو وروسته د شالید پیل لپاره شته; هغه توکی چې غواړي وسیله اوس خلاصه وي داسې نه دی.

د لا سختې طبقې ټاکل هڅوونکي دي او همدا هغه څه دي چې په تړلي تلیفون کې on-demand پروفایل ماتوي.

له طبقې بدلون وروسته توکی له سره جوړ کړئ، نه دا چې د موجود توکي ځانګړنې سمې کړئ، بیا پروتوکول له نوي حوالې سره بیا خوندي کړئ. په موجود توکي د ځانګړنو بدلونونه تل هغه چلند نه تولیدوي چې سند ورته اشاره کوي، او بیا جوړ شوی توکی شک لېرې کوي.

څرخېدل هغه ځای دی چې خوندي پروفایلونه خرابېږي

په کیلي زنځیر کې پټنوم بدلول په اتوماتيک ډول هغه نه بدلوي چې خوندي پروفایل ورته اشاره کوي. توکی حذفول لا بدتر دي: پروفایل هغه څه ته حواله ساتي چې نور نشته، او ناکامي د تصدیق د ردېدو په څېر ښکاري.

په یوه ترتیب څرخه وکړئ. توکی تازه کړئ، نوې تلپاتې حواله وغواړئ، پروتوکول بیا خوندي کړئ، بیا د اپلیکیشن په بند حالت کې ونښلئ تر څو ثابته کړئ چې ډیمون لا هم هغه حل کولای شي. د کاروونکي پټنوم او شریک راز په جلا توکو کې وساتئ تر څو هر یو خپل مهالویش سره وڅرخي، او هیڅکله د پوښتنې قاموس یا پخپله حواله لاګ مه کوئ. لاستی راز نه دی، خو هغه ته نقشه ده.