Apple VPN On Demand کے ڈومین قواعد ٹنل کیسے شروع کرتے ہیں
ڈومین قاعدہ صرف یہ طے کرتا ہے کہ ٹنل کب کھلے گا۔ connect-if-needed DNS پروب کیسے کام کرتا ہے، راستے اب بھی ٹریفک کیوں منتخب کرتے ہیں اور پروفائل کیسے جانچیں۔
ٹنل اس وقت کھلتا ہے جب آپ ایک اندرونی نام کی درخواست کرتے ہیں اور بند رہتا ہے جب اگلی ایپ کو اتنی ہی ضرورت ہو۔ یہ ایپ میں خرابی نہیں؛ یہ ڈومین قاعدے کی شکل ہے۔ Apple کی on-demand ترتیب کنکشن بنانے کی شرائط بیان کرتی ہے، اور ان شرائط کی ڈومین شکل ایک پیکٹ کے حرکت کرنے سے پہلے سسٹم ریزولور سے سوال پوچھتی ہے۔ دو سوال مسلسل مل جاتے ہیں: ٹنل کب اوپر آنا چاہیے، اور ٹنل موجود ہونے پر کیا لے کر چلتا ہے۔ پہلا ٹرگر ہے، دوسرا راستوں اور ریزولور کی پالیسی ہے، اور ایک پروفائل عام طور پر دونوں کو ایک ہی payload میں سیٹ کرتی ہے، اسی لیے درست ڈومین قاعدہ بھی آپ کو غلط نیٹ ورک پر چھوڑ سکتا ہے۔
ٹرگر اور ٹریفک کا انتخاب مختلف تہوں میں ہیں
on-demand قاعدہ VPN payload کی on-demand لغت میں رہتا ہے: قواعد کی ترتیب شدہ فہرست، ہر ایک میں ایک عمل اور مماثلت کی شرائط کا مجموعہ۔ سسٹم ان کا جائزہ لیتا ہے جب کنیکٹیویٹی بدلتی ہے یا جب کوئی چیز نیٹ ورک تک پہنچنے کی کوشش کرتی ہے، اور عمل فیصلہ کرتا ہے کہ ٹنل اوپر اٹھایا جائے، جائزہ لیا جائے، منقطع کیا جائے یا نظر انداز کیا جائے۔ یہ سب ایپ کو ساکٹ ملنے سے پہلے پلیٹ فارم کی نیٹ ورکنگ پرت میں ہوتا ہے۔
اس کے بعد کلیدوں کا الگ گروپ آتا ہے: ٹنل کی 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 |
کیپٹیو پورٹل اپنی الگ سطر کے حقدار ہیں، کیونکہ ہوٹل اور ہوائی اڈے کی 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 راستہ ڈھانپتی ہے، اور ایپ ٹنل کے دائرے میں ہے۔ پانچوں درست ہوں تو قاعدہ اپنا کام کر رہا ہے اور خرابی راستے میں مزید آگے ہے۔