Mac VPN اور PAC پراکسی: دو فیصلے، ایک ترتیب نہیں

آپ کا Mac ایک پالیسی اسکرپٹ ڈاؤن لوڈ کرتا ہے اور پھر اس اسکرپٹ سے پوچھتا ہے کہ درخواست کو کون سا واسطہ استعمال کرنا چاہیے، جبکہ ٹنل صرف یہ طے کرتا ہے کہ منتخب ہاپ تک کیسے پہنچنا ہے۔ دونوں جواب ایک ہی سوکٹ پر آتے ہیں، اس لیے دونوں کے کامیاب ہونے کے بعد ناکام ہونے والی درخواست دو ہونے کے باوجود ایک خرابی جیسی لگتی ہے۔ ڈاؤن لوڈ کو انتخاب سے اور انتخاب کو راستے سے الگ کرنا ان ٹکٹوں کا زیادہ تر کام ہے۔ نیچے دیا گیا ترتیب وہی کرتا ہے جو macOS واقعی کرتا ہے، ان جانچوں کے ساتھ جو ہر مرحلے کو نظر آنے والا بناتی ہیں۔

PAC پتہ اور پراکسی کہاں الگ ہوتے ہیں

https://config.corp.example/proxy.pac جیسا پتہ ڈاؤن لوڈ کیے جانے والے دستاویز کا نام دیتا ہے، اور وہ دستاویز اس سرور کا نام دیتا ہے جس سے ٹریفک گزرے۔ URL کو پراکسی ہوسٹ فیلڈ میں چپکانا کلائنٹ سے کہتا ہے کہ ایسی فائل سرور سے پراکسی کنکشن کھولے جو کبھی ایسا نہیں سنتا۔ فائل کے اندر ایک فنکشن ہے جسے کلائنٹ ہر درخواست پر بلاتا ہے، اور اس کی واپسی کی قدر اسی ایک منزل کے لیے اگلی ہاپ ہے۔ یہ بالواسطگی بتاتی ہے کہ ایک ہی نیٹ ورک سروس پر دو مشینیں، دونوں کے پاس درست URL ہونے کے باوجود، مختلف کیوں برتاؤ کر سکتی ہیں۔ یہ یہ بھی بتاتی ہے کہ پالیسی میں تبدیلی کسی کے خود پراکسی کو چھوئے بغیر کیوں نافذ ہو جاتی ہے۔

نیچے کسی بھی چیز کی تشریح سے پہلے اسکرپٹ پڑھیں، کیونکہ اس کے اندر کے قواعد تنظیم کی استثنائیں اور ان کے لاگو ہونے کی ترتیب رکھتے ہیں۔ ابتدائی وسیع رینج بعد کی اندرونی لاحقہ کو چھپا سکتی ہے، اور جس ہوسٹ کو واضح طور پر پراکسی نظرانداز کرنی چاہیے وہ اسے استعمال کرتا رہتا ہے۔ جب کوئی اصرار کرے کہ پالیسی غلط ہے، تو اسکرپٹ ہی واحد جگہ ہے جہاں وہ دعویٰ طے ہوتا ہے۔

اسکرپٹ کو کچھ بھی طے کرنے سے پہلے حاصل کرنا ضروری ہے

پالیسی ڈاؤن لوڈ کرنے کے لیے حل شدہ نام اور فائل فراہم کرنے والے تک راستہ درکار ہے، اور منسلک ٹنل دونوں میں سے کوئی چیز یقینی نہیں بناتی۔ اگر ہوسٹ صرف نجی DNS سے حل ہوتا ہے، تو اس وقت استعمال ہونے والا حل کنندہ فیصلہ کرتا ہے کہ ڈاؤن لوڈ شروع ہو سکتا ہے یا نہیں۔ اگر ہوسٹ نجی رینج میں ہے، تو راستہ اسی مشین سے ہونا چاہیے، کسی ساتھی کے لیپ ٹاپ سے نہیں۔ پچھلے سیشن میں کیش شدہ نقل کیش ختم ہونے یا مشین دوبارہ شروع ہونے تک یہ سب چھپائے رکھتی ہے۔

نیچے دی گئی تین جانچیں ترتیب سے چلائیں اور پہلی ناکامی پر رک جائیں، کیونکہ مراحل کی وجہ ایک نہیں ہے۔ مل کر وہ دکھاتی ہیں کہ پالیسی ترتیب دی گئی ہے یا نہیں، اس تک پہنچا جا سکتا ہے یا نہیں، اور یہ کیا واپس دیتی ہے۔

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

پہلا کمانڈ فعال سروس کے لیے پراکسی لغت چھاپتا ہے، جس میں کوئی بھی خودکار ترتیب URL شامل ہے جو سسٹم رکھتا ہے۔ دوسرا ایک نامزد سروس سے منسلک URL بتاتا ہے، جو Wi-Fi اور Ethernet کے درمیان چلنے والے لیپ ٹاپ پر اہم ہے۔ تیسرا فائل کو پیش کیے بغیر لاتا ہے، تاکہ 404، وقت ختم ہونا اور حل کنندہ کی ناکامی الگ پہچانی جا سکیں۔ اگر وہ آخری کمانڈ اسکرپٹ واپس دے جبکہ ایپلیکیشنز ابھی بھی ناکام ہوں، تو مسئلہ پہلے ہی حاصل کرنے سے آگے بڑھ چکا ہے۔

DIRECT جواب واقعی کیا چھوڑتا ہے

PAC تفصیل کلائنٹ کو چھوٹی ذخیرہ الفاظ دیتی ہے، اور DIRECT اس کا ایک لفظ ہے۔ یہ لفظ کلائنٹ سے کہتا ہے کہ اس درخواست کے لیے پراکسی چھوڑ دے اور اس بارے میں کچھ نہیں کہتا کہ سوکٹ اس کے بعد کون سا انٹرفیس استعمال کرے گا۔ مکمل ٹنل پر براہ راست سوکٹ پھر بھی VPN سے ہی باہر نکلتا ہے اور منزل کو پھر بھی ٹنل کا اخراجی پتہ دکھاتا ہے۔

DIRECT کو VPN سے باہر پڑھنا وہ غلطی ہے جو لوگوں کو غلط سیٹنگز پینل تک بھیجتی ہے۔ آئینے والی تصویر بھی اتنی ہی عام ہے، کیونکہ نجی پراکسی تک تقسیم شدہ راستے سے پہنچا جا سکتا ہے جبکہ باقی مشین ٹنل سے باہر رہتی ہے۔ تب منزل جو بتاتی ہے وہ خود پراکسی کے اخراج کا ہوتا ہے، جو کسی اور ملک میں ہو سکتا ہے۔ ایک اندرونی ہوسٹ اور ایک عوامی ہوسٹ کے لیے توقع لکھنا اسے جلد بے نقاب کر دیتا ہے، کیونکہ اسکرپٹ اکثر دونوں کو الگ جواب دیتا ہے۔ ایک بار جان لیں کہ کس ہاپ نے پتہ بنایا، تو رپورٹ پراسرار نہیں رہتی۔

تین ناکامیاں جو ایک ہی غلطی صفحے کے طور پر ظاہر ہوتی ہیں

پالیسی ڈاؤن لوڈ ہونے میں ناکام ہو سکتی ہے، منتخب پراکسی ناقابل رسائی ہو سکتی ہے، اور سروس تک پہنچنے والی درخواست وہاں پھر بھی رد ہو سکتی ہے۔ تینوں وقت ختم ہونے یا عام غلطی صفحے کے طور پر آتی ہیں، اور کوئی بھی ٹوٹے ہوئے مرحلے کا نام نہیں لیتی۔ غلطی کے ساتھ فیصلہ قید کرنا ہی انہیں الگ کرتا ہے۔ نیچے دیے گئے دو پروب اسکرپٹ کے منتخب کردہ ہاپ کو جانچتے ہیں، ہر اس شاخ کے لیے ایک جو یہ واپس دے سکتی ہے۔

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

پراکسی سے مکمل کنکشن سوال کو توثیق یا خود پراکسی کی پالیسی کی طرف منتقل کرتا ہے، جس کا مالک الگ ہے۔ راستے میں پراکسی کے بغیر اندرونی ہوسٹ سے مکمل کنکشن راستے کو خارج کرتا ہے اور پالیسی کی طرف اشارہ کرتا ہے۔ دونوں کمانڈز macOS پراکسی لغت کو نظرانداز کرتے ہیں جب تک کہ شیل پراکسی متغیرات برآمد نہ کرے، اس لیے پہلے انہیں صاف کریں۔ دو پروبوں میں سے کوئی ایک دوسرے کو ثابت نہیں کرتا، اسی لیے ایک غلطی صفحہ اتنی دیر گمراہ کرتا ہے۔

ٹکٹ کے ساتھ کیا سپرد کرنا ہے

فعال نیٹ ورک سروس، PAC URL، ناکام ہونے والے ہوسٹ کے لیے تشخیصی نتیجہ اور وہ مرحلہ جہاں غلطی ظاہر ہوئی بھیجیں۔ یہ چار اگلے شخص کو یہ اندازہ لگانے کے بجائے کہ کون سی تہہ شامل تھی، فیصلہ دوبارہ بنانے دیتے ہیں۔ ٹیسٹ کے لمحے ٹنل کی حالت شامل کریں، کیونکہ دوبارہ جڑنے سے پہلے لیے گئے نتیجے پرانی ہوتی ہے۔ اسکرپٹ کی نظرثانی بھی رکھیں، کیونکہ پالیسی فائل بغیر اطلاع کے بدلتی ہے اور کل کا جواب اب درست نہ ہو۔

ریکارڈ کریں کہ جب اسکرپٹ حاصل نہ کی جا سکے تو کلائنٹ کیسا برتاؤ کرتا ہے، کیونکہ عمل درآمد مختلف ہیں اور پراکسی کا فیصلہ پورے آلے کا کِل سوئچ نہیں ہے۔ کچھ براہ راست کنکشن پر واپس آتے ہیں اور کچھ بند حالت میں ناکام ہوتے ہیں، اور یہ فرق بدل دیتا ہے کہ خلل ٹوٹی پراکسی جیسا لگتا ہے یا چلتی پالیسی جیسا۔ کسی واقعے کے دوران اس پر انحصار کرنے سے پہلے درست کلائنٹ اور ورژن کے لیے برتاؤ کی تصدیق کریں۔