کیوں ہوسٹ کے URL کے ساتھ مہمان VM میں PAC پراکسی ناکام ہوتی ہے

«ہوسٹ یہ PAC فائل استعمال کرتا ہے، اس لیے میں نے وہی URL VM میں رکھا» ایک معقول جملہ اور ادھورا منصوبہ ہے۔ PAC URL کسی پالیسی اسکرپٹ کی طرف اشارہ کرتا ہے، پراکسی کی طرف نہیں۔ جب تک مہمان اُس اسکرپٹ کو نہیں لا سکتا، مہمان کے اپنے پتوں سے اُس کی جانچ نہیں کر سکتا اور پھر اسکرپٹ کے بتائے ہوئے کسی بھی پراکسی تک نہیں پہنچ سکتا، URL صرف ترتیبات کے خانے میں ایک سٹرنگ ہے۔ مجازی مشینوں میں پراکسی پالیسی کے گرد زیادہ تر الجھن اُس ایک سطر کو پوری ترتیب سمجھنے سے پیدا ہوتی ہے۔

PAC URL ایک اسکرپٹ ہے، پراکسی نہیں

فائل میں ایک فنکشن ہے جو URL اور ہوسٹ لیتا ہے اور پراکسی کی تفصیل یا DIRECT کا لفظ واپس کرتا ہے۔ URL میں کچھ بھی ایپلیکیشن کو نہیں بتاتا کہ ٹریفک کہاں بھیجنا ہے؛ یہ فیصلہ رن ٹائم پر، اسکرپٹ کے اندر، اُن اعداد و شمار کے ساتھ ہوتا ہے جو اسکرپٹ پلیٹ فارم سے مانگتا ہے۔ PAC URL قبول کرنے والا ترتیبات کا ڈائیلاگ فیصلہ سازی کے عمل کی طرف اشارہ قبول کرتا ہے۔

یہی فرق وجہ ہے کہ URL کی نقل کرنا کام ہوا جیسا لگ سکتا ہے۔ خانہ بھر جاتا ہے، ترتیب محفوظ ہوتی ہے، اور ناکامی صرف بعد میں ظاہر ہوتی ہے، جب اسکرپٹ نہیں لایا جا سکتا یا جب وہ ایسی پراکسی واپس کرتا ہے جہاں مہمان نہیں پہنچ سکتا۔

چاروں مراحل ہر ایک الگ انداز میں ناکام ہوتے ہیں

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

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

اگر وہ درخواست مہمان سے ناکام ہوتی ہے اور ہوسٹ سے کام کرتی ہے، تو مسئلہ اسکرپٹ کے مواد میں نہیں، مہمان کے PAC سرور تک راستے میں ہے۔ اگر وہ JavaScript فائل واپس کرتی ہے، تو دوسرے مرحلے پر جائیں اور معلوم کریں کہ اسکرپٹ مہمان کے سیاق کے لیے کیا فیصلہ کرتا ہے۔

وہی اسکرپٹ VM کے اندر مختلف فیصلہ کرتا ہے

PAC فنکشنز مطلوبہ ہوسٹ اور جانچ کرنے والی مشین کے بارے میں معلومات دیکھ سکتے ہیں۔ کلائنٹ کے اپنے پتے پر بنایا گیا اصول، مثلاً جو انٹرفیس پتہ یا سب نیٹ رکنیت جانچتا ہے، جسمانی ہوسٹ کا نہیں بلکہ مہمان کا پتہ دیکھے گا۔ ہوسٹ کی طرف NAT کے پیچھے یہ الگ پتے ہیں، اسی لیے وہی اسکرپٹ کوئی دوسری پراکسی چن سکتا ہے یا VM کے اندر DIRECT پر واپس جا سکتا ہے۔

یہ اسکرپٹ میں کوئی نقص نہیں ہے۔ اسکرپٹ وہی کر رہا ہے جس کے لیے لکھا گیا تھا، کسی دوسرے ان پٹ کے ساتھ، اور یہی اُس الجھی ہوئی رپورٹ کی وضاحت کرتا ہے جس میں ہوسٹ پراکسی استعمال کرتا ہے اور مہمان سیدھا جڑتا ہے۔ فیصلے کے بارے میں سوچنے کے بجائے اُسے دوبارہ پیدا کریں: پتہ اور URL لینے والا PAC جانچنے والا، اگر آپ کی تقسیم میں ہو، ایک ہی حکم میں سوال طے کر دیتا ہے۔ ورنہ اُس ایپلیکیشن سے آزمائیں جو واقعی استعمال ہوگی، اور اندازہ لگانے کے بجائے اُس کا پراکسی لاگ پڑھیں۔

یہ نتیجہ نہ نکالیں کہ مہمان نے ہوسٹ کی پراکسی ترتیبات ورثے میں لی ہیں کیونکہ اُس کا ٹریفک ہوسٹ کی طرف کے ترجمے سے گزرتا ہے۔ نیٹ ورک ترجمہ پیکٹ آگے بھیجتا ہے؛ یہ ایپلیکیشن کی ترتیب کی نقل نہیں کرتا، اور سسٹم پراکسی ایپلیکیشن کی ترتیب ہے۔

وہ اوزار جو PAC بالکل نہیں پڑھتے

کمانڈ لائن اوزار الگ حد ہیں، اور یہیں بہت وقت ضائع ہوتا ہے۔ curl PAC فائلیں نہیں چلاتا، جیسا کہ اُس کی پراکسی دستاویزات واضح طور پر کہتی ہیں۔ پراکسی متغیر کو PAC ڈاؤن لوڈ URL کی طرف اشارہ کرنا اسکرپٹ کو پراکسی کا آخری نقطہ نہیں بناتا؛ اوزار JavaScript فائل سے HTTP بولنے کی کوشش کرے گا اور ایسے ناکام ہوگا جو نیٹ ورک مسئلے جیسا لگے۔

یہی بات بہت سے پیکیج مینیجرز، زبانوں کے رن ٹائم اور بلڈ اوزار پر لاگو ہوتی ہے، جو صرف واضح پراکسی متغیرات یا اپنی ترتیب مانتے ہیں۔ اگر آپ کے لیے اہم آزمائش CLI اوزار ہے، تو اُسے اُس ٹھوس پراکسی کے ساتھ ترتیب دیں جو PAC اسکرپٹ چنتا، اور لکھیں کہ آپ اُس انتخاب تک کیسے پہنچے تاکہ اگلا شخص اُسے دہرا سکے۔

Linux پر ڈیسک ٹاپ ایپلیکیشنز کے لیے، سسٹم ترتیب کو خودکار موڈ میں رکھنا اور URL بھی دینا ہوگا؛ موڈ کے ابھی دستی ہونے کے دوران محفوظ کیا گیا URL کچھ نہیں کرتا۔ دونوں جانچیں، اور اُنہیں مہمان کے اندر جانچیں:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT بھی ایک فیصلہ ہے

PAC نتیجہ DIRECT کا مطلب ہے کہ ایپلیکیشن HTTP پراکسی کو نظر انداز کرتی ہے، یہ نہیں کہ وہ نیٹ ورک سے بچ نکلی ہے۔ نتیجے میں بننے والا کنکشن اب بھی سرنگ کے ذریعے آپریٹنگ سسٹم کے راستے پر چل سکتا ہے، یا ایسی وجوہات سے ناکام ہو سکتا ہے جن کا پراکسی کے استعمال سے کوئی تعلق نہیں۔ برعکس، پراکسی کا نتیجہ ایک ایپلیکیشن کی درخواست بیان کرتا ہے، مہمان کے ہر عمل کا نہیں۔

اس لیے اُسی سمت میں تصدیق کریں جس میں ضرورت لکھی گئی تھی۔ اگر ضرورت یہ ہے کہ «یہ ایپلیکیشن اندرونی سائٹ تک پہنچتی ہے»، تو ثابت کریں کہ وہ ایپلیکیشن پہنچتی ہے، اور لکھیں کہ کون سی پراکسی یا راستہ اُسے لے گیا۔ اگر ضرورت یہ ہے کہ «VM کارپوریٹ نیٹ ورک پر ہے»، تو منتخب پراکسی کے ذریعے چلنے والا براؤزر اُس براؤزر کے لیے ثبوت ہے اور اس سے زیادہ کچھ نہیں۔

آزمائش کے گزرنے کے لیے ہوسٹ کی سرنگ بند کرنے یا فارورڈنگ پالیسی نرم کرنے کے بجائے مہمان کے اندر زنجیر درست کریں۔ زنجیر میں چار کڑیاں ہیں، اور اُن میں سے کوئی ایک چھوڑنے والی تبدیلی اگلی بار اسکرپٹ کی تازہ کاری یا مہمان کے پتے کی تبدیلی تک قائم رہے گی۔