برانچ براؤزر سے پراکسی تک: دو کنکشن، دو راستے

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

مرحلہ 1: دونوں بہاؤ لکھیں

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

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

مختلف ذرائع، مختلف راستے، مختلف اجازتیں۔ خاکہ تبدیلی ریکارڈ میں رکھیں، کیونکہ ہر بعد کی جانچ اس کے دو حصوں میں سے ایک کا حوالہ دیتی ہے۔

مرحلہ 2: براؤزر کو سننے والے تک راستہ دیں

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

انٹرنیٹ پر غیر محدود پراکسی شائع کرنے کے بجائے مطلوبہ سروس کے لیے تنگ نیٹ ورک قاعدہ لگائیں۔ پراکسی اندرونی نیٹ ورک پر رہ سکتی ہے جب اس کے مطلوبہ کلائنٹس کے پاس اس تک معاون راستہ ہو۔

مرحلہ 3: صرف راستے کا جدول نہیں، براؤزر ترتیب دیں

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

لکھیں کہ کون سی ایپلیکیشنز سیٹنگ کا احترام کرتی ہیں۔ میل کلائنٹس، اپ ڈیٹرز اور گیمز اکثر احترام نہیں کرتے، اور وہ سادہ راستہ استعمال کرتے رہیں گے۔

مرحلہ 4: پراکسی کا آگے کا کنکشن ثابت کریں

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

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

مرحلہ 5: چار ناکامیوں میں فرق کریں

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

جو حد آپ نے دیکھی اس کی رپورٹ کریں، یہ خلاصہ نہیں کہ VPN ناکام ہو گیا۔

مرحلہ 6: دائرہ کار طے کریں اور متبادل کی منصوبہ بندی کریں

طے کریں کہ پراکسی یا سرنگ دستیاب نہ ہونے پر کیا ہوگا، اور واضح کہیں کہ یہ ڈیزائن کون سی ٹریفک کا احاطہ کرتا ہے۔ یہ پراکسی سیٹنگ کا احترام کرنے والے کلائنٹس سے ویب رسائی لے جاتا ہے؛ یہ میل، من مانی ڈیوائس پروٹوکول یا ترتیب کو نظر انداز کرنے والا سافٹ ویئر نہیں لے جاتا۔

ڈیزائن کو مزید کلائنٹس تک بڑھانے سے پہلے منظور شدہ منصوبے کے تحت مطلوبہ براؤزر عمل اور ایک مطلوبہ انکار کی تصدیق کریں۔