د Apple VPN On Demand د ډومین قواعد څنګه ټنل پیلوي
ډومین قاعده یوازې دا ټاکي چې ټنل کله پرانیستل کیږي. connect-if-needed DNS پروب څنګه کار کوي، ولې لارې اوس هم ترافیک غوره کوي او پروفایل څنګه ازموو.
ټنل هغه وخت پرانیستل کیږي کله چې تاسو یو داخلي نوم غواړئ، او بند پاتې کیږي کله چې بل اپلیکیشن ورته هماغسې اړتیا ولري. دا د اپلیکیشن خطا نه ده؛ دا د ډومین قاعدې بڼه ده. د Apple on-demand ترتیبات د اړیکې جوړولو شرایط بیانوي، او د دې شرایطو ډومین بڼه د یوې بستې له خوځیدو مخکې د سیسټم ریزولور څخه پوښتنه کوي. دوه پوښتنې تل ګډیږي: ټنل باید کله پورته شي، او ټنل چې شتون ولري څه وړي. لومړی ټریګر دی، دویم د لارو او ریزولور پالیسي ده، او یو پروفایل معمولاً دواړه په یوه payload کې ټاکي، نو ښه ډومین قاعده هم کولی شي تاسو په غلط شبکه کې پرېږدي.
ټریګر او د ترافیک انتخاب په بیلابیلو طبقو کې دي
on-demand قاعده د VPN payload په on-demand قاموس کې ژوند کوي: د قاعدو ترتیب شوې لیست، هر یو یې یو عمل او د ورته والي شرایط لري. سیسټم هغه ارزوي کله چې اړیکه بدله شي یا کله چې یو څه شبکې ته د رسیدو هڅه وکړي، او عمل فیصله کوي چې ټنل پورته شي، ارزول شي، قطع شي یا له پامه وغورځول شي. دا ټول د پلیټ فارم د شبکې په طبقه کې، ستاسو اپلیکیشن له socket مخکې پیښیږي.
بیا راتلونکی جلا کیلي ګروپ دی: د ټنل IPv4 او IPv6 تنظیمات، د هغې شامل او خارج شوي لارې، د DNS سرور پتې، او په iOS او iPadOS کې د هر اپلیکیشن نقشه چې ټاکي کوم اپلیکیشنونه کولی شي ټنل وکاروي. یو پروفایل کولی شي پراخه ټریګر له تنګې لارې سره جوړه کړي، یا تنګ ټریګر له اصلي لارې سره. یوازې نیمه ولولئ، بله نیمه به د خرابۍ په څیر ښکاره شي.
زه یو لابراتوار پروفایل لرم چې کله د داخلي ډومین لاندې یو څه وغوښتل شي نښلوي، خو ټنل ته یوازې یوه /16 لارښوونه کوي. دا په خپل payload کې لیکل شوي کار کوي، او دا هغه ډول پروفایل هم دی چې ټکټونه جوړوي: خلک فکر کوي چې نښلول شوی ټنل معنی دا ده چې د دوی ترافیک دننه دی.
ډومین قاعده ریزولور څخه واقعاً څه پوښتي
د قاعدې ډومین بڼه، چې ډیری وخت connect-if-needed بلل کیږي، د بستې payload نه ګوري او URL نه څاري. کله چې نوم حل شي، سیسټم هغه د قاعدې ډومینونو سره پرتله کوي او د ورته والي په صورت کې پوښتنه کوي چې ایا دا نوم د ټنل لخوا ورکړل شوي DNS سرورونو له لارې حل کیدای شي. که د ټنل ریزولور ځواب ووایه، نوم داخلي ګڼل کیږي او اړیکه پیل کیږي. که د سیمه ییز ریزولور ځواب ووایه، نوم بهرنی ګڼل کیږي او ټنل نه ښکاره کیږي. د Apple د ځای پرځای کولو عمومي کتنه دا د شبکې کشف او بیا د اړیکې ارزونه بولي.
دوه پایلې ترې راځي. پروفایل باید د ټنل دننه DNS سرورونه ونوموي؛ د ټنل ریزولور پرته ډومین قاعده د پرتله کولو لپاره هیڅ نه لري، نو ارزونه نشي کولی هغه ورته والی تولید کړي چې تاسو یې تمه لرئ. او پلټنه باید د سیسټم ریزولور ته ورسيږي. هغه اپلیکیشن یا براوزر چې خپل کوډ شوی DNS چلوي، هغه غځېدنه چې په سیمه ییز ډول ځواب وایي، یا لفظي پتې ته اړیکه هېڅکله هغه نوم حل نه تولیدوي چې قاعده یې تمه لرله. زما یو له ترټولو اوږدو غرمې وروسته وختونو څخه هغه وخت پای ته ورسید کله چې وموندله چې د ټنل مخې ته کلاینټ DNS over HTTPS کاروي.
کیشینګ هم ټریګر لرې کوي. هغه نوم چې لا دمخه په کیش کې دی ممکن د هغه پروب پرته ځواب شي چې ټنل یې پیل کړی و، نو هغه قاعده چې پرون یې کار کاوه د بیا پیل وروسته یا د ټنل د څه وخت پورته پاتې کیدو وروسته ناکامه شي. په macOS کې sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder حالت بیا تنظیموي؛ په iOS کې د الوتنې حالت چالانول او بندول یا د وسیلې بیا پیل کول ورته پاک پیل درکوي.
د ورته والي ساحه: نومونه، اپلیکیشنونه او شبکې
ډومین ورته والی له څو ډولونو څخه یو دی. قاعده کولی شي د انټرفیس ډول (Wi-Fi، ګرځنده، Ethernet) او یو ځانګړي SSID سره هم ورته شي، او د هر اپلیکیشن یا Safari ډومین ننوتنې ټنل له یو کاري جریان سره تړي. همدا تړاو هغه عجیبه تجربه تشریح کوي چې یوازې یو اپلیکیشن د نورو ټولو څخه بېل چلند کوي: نور اپلیکیشنونه د ټنل له ساحې بهر دي، نو دوی سیمه ییزه لار کاروي حتی کله چې د ټنل آیکون وایي نښلول شوی دی.
ترتیب د خلکو له تمې ډیر مهم دی. قواعد په ترتیب ارزول کیږي او لومړی ورته والی عمل ورکوي، نو یوه پراخه هرې-Wi-Fi-ته-ونښلو قاعده چې د تنګې ډومین قاعدې پورته وي په غلې ډول ګټي او ډومین قاعده ازموینه ناشونده کوي. مخکې له دې چې د ډومین لیست بیا ولیکئ، تایید کړئ چې کومه پخوانۍ قاعده لا دمخه ورته شوې نه ده.
له همدې امله always-on یوازې سخت on-demand قاعده نه ده. د always-on پلي کول جلا ځای پرځای کولو حالت دی چې خپل څارنې او مدیریت اړتیاوې لري؛ دا د نوم په ځواب ورکولو پرځای ټنل خلاص ساتي. که تاسو هغه ټنل ته اړتیا لرئ چې هېڅکله نه لوېږي، ډومین قاعده غلط وسیله ده.
هغه ناکامۍ چې ماتې قاعدې ته ورته دي
د ډومین قاعدې د نه کار کولو ډیری راپورونه په پنځو ځایونو کې یو ته ورسیږي، او یوازې وروستی یې د قاعدې متن دی.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
Captive پورتالونه خپلې کرښې ته وړ دي، ځکه چې د هوټل او هوایی ډګر Wi-Fi هغه پلټنه منځ ته راوړي چې قاعده پرې تکیه ده. تر هغه چې پورتال وسیله داخله نکړي، د ټنل DNS سرور نه رسیږي، پروب ناکام کیږي، او ناکامي د غلط لیکل شوي ډومین په څیر ښکاري. تصدیق بل غلې حالت دی: قاعده کولی شي وچوي، ټنل کولی شي نښلیدل پیل کړي، او اړیکه د پای نیټې شوې سند یا په بله ښودنه کې راڅرګند شوي غوښتنې له امله مري.
IPv6 هغه ډول جوړوي چې غلط تشخیص یې اسانه دی. دواړه پتې کورنۍ لرونکي نوم ته ممکن لومړی د AAAA ریکارډ څخه ځواب ورکړل شي، پداسې حال کې چې د ټنل د لارو لیست یوازې IPv4 لري. یو براوزر بریالی کیږي، بل ناکام، او د ډومین لیست په بشپړ ډول بې ګناه دی.
د ریښتیني غوښتنې سره، په دې ترتیب ازموینه وکړئ
د اټکل کولو مخکې پالیسي ولولئ. په macOS کې sudo profiles show -type configuration نصب شوي پروفایلونه چې VPN payload هم پکې دی چاپوي، scutil --nc list د خدمت حالت ښیي، او scutil --nc show <service> هغه on-demand قاموس چاپوي چې سیسټم یې کاروي. په مدیریت شوي iPhone یا iPad کې هماغه payload د مدیریت کنسول یا MDM راپور څخه راځي. د شبکې لاګونه په macOS کې د log stream --predicate 'subsystem == "com.apple.networkextension"' سره، او کله چې تلیفون نښلول شوی وي د وسیلې کنسول له لارې شتون لري.
بیا هغه هوسټ نوم سره ازموینه وکړئ چې په دې ناسته کې مخکې نه وي پوښتل شوی. د ټنل په DNS زون کې هغه نوم وټاکئ چې تاسو پوهیږئ په داخلي ډول حل کیږي، یو ځل یې وغواړئ، او وګورئ چې ټنل ښکاري که نه. هماغه پلټنه دوه ځله چل کړئ: دویمه هڅه د کیش لار تمرینوي، او د دواړو توپیر تاسو ته وایي چې ټریګر حل دی که لارښوونه.
د ټنل له پورته کیدو وروسته دواړه طبقې جلا جلا وګورئ. netstat -rn -f inet او netstat -rn -f inet6 ښیي چې هر مخکښ چیرته اشاره کوي، scutil --dns د ریزولورونو ترتیب او کوم انټرفیس چې کوم ریزولور لري ښیي، او nettop -m route ښیي چې کوم انټرفیس بایټونه وړي. که ټنل پورته وي او ریزولور سم وي خو سرچینه لا هم ناکامه وي، قاعده سمول بند کړئ؛ د سرور اړخ تصویب او د بیرته ستنیدو لار وګورئ.
کله چې قاعده بل چا ته وي
که ټنل د قطع کولو وروسته بیا ښکاره شي، قاعده معمولاً پروفایل ته اړه لري نه اپلیکیشن ته: هغه ترتیبات چې د MDM له لارې لېږل شوي، پاتې شخصي پروفایل، یا هغه پروفایل چې بل کلاینټ نصب کړی. sudo profiles show -type configuration او د on-demand کیلیو پلټنه به یې تنګه کړي، او د لرې کولو لار پروفایل دی، د مینو بار سویچ نه. د خدمت ننوتنې یا اپلیکیشن ړنګول قاعده پرېږدي، او بل نصب یې بیا میراث اخلي.
یوه ازموینه مالکیت فیصله کوي: قطع کړئ، انتظار وکړئ، بیا داخلي نوم وغواړئ. که ټنل بیرته راشي، ټریګر د ډیزاین مطابق کار کوي او خلاصه پوښتنه دا ده چې څوک یې مدیریت کوي او ایا هغه ساحه هغه ده چې تاسو یې غواړئ.
مخکې له دې چې دا د خطا په توګه ثبت کړئ، هماغه پنځه ګوري وکړئ: په payload کې د ټنل ریزولور پتې شته، نوم کیش شوی نه و، کومه پخوانۍ قاعده لا دمخه ورته شوې نه وه، د لارو لیست AAAA لار پوښي، او اپلیکیشن د ټنل په ساحه کې دی. کله چې پنځه واړه سم وي، قاعده خپله کار کوي او خرابي د لارې په اوږدو کې نوره مخکې ده.