کارپوریٹ VPN جڑنے پر ڈیبگ پراکسی اندھی ہو جاتی ہے

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

Windows ہر کنکشن کے لیے الگ پراکسی رکھتا ہے

انٹرنیٹ اختیارات میں دو پرتیں ہیں جو ڈائیلاگ میں ایک جیسی دکھتی ہیں۔ مقامی نیٹ ورک کی ترتیبات عام مقامی کنکشن پر لاگو ہوتی ہیں، جبکہ ڈائل اپ یا VPN اندراج HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections کے تحت اپنی نقل بائنری قدر کے طور پر رکھتا ہے۔ جانی پہچانی عالمی رجسٹری قدروں کو لکھنے سے وہ نقل تازہ نہیں ہوتی۔

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

ایک اندراج بدلنے کا تعاون یافتہ طریقہ WinINET کنکشن آپشن API ہے: کنکشن کا نام، جھنڈے، پراکسی سرور اور بائی پاس فہرست کے ساتھ INTERNET_PER_CONN_OPTION_LIST بھریں، لاگو کریں، پھر تازہ کریں۔ فوری جانچ کے لیے ٹنل اندراج کا اپنا ترتیبات ڈائیلاگ کھولیں اور اس کا پراکسی پینل مقامی نیٹ ورک پینل سے موازنہ کریں؛ کہاں دیکھنا ہے معلوم ہو تو فرق عام طور پر واضح ہوتا ہے۔

منظم PAC خود کو دوبارہ چالو کر سکتا ہے

macOS میں خودکار پراکسی کنفیگریشن اسکرپٹ اور خودکار پراکسی دریافت نیٹ ورک سروس کی خصوصیات ہیں، مشین کی نہیں۔ کنفیگریشن پروفائل انہیں لازمی بنا سکتا ہے، اس لیے نشان ہٹانے کے بعد وہ پھر ظاہر ہوتے ہیں، اور پھر ہر درخواست اس پراکسی پر جاتی ہے جو اسکرپٹ منتخب کرتا ہے۔

جانچ کریں اور، اگر مجاز ہیں، ٹریفک لے جانے والی سروس کے لیے وہ دو سوئچ بند کریں:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

اندازے کے بجائے سروس کا اصل نام استعمال کریں۔ Wi-Fi اور USB ایتھرنیٹ اڈاپٹر دونوں والے لیپ ٹاپ میں ایسی دو ہوتی ہیں، اور آپ کا ٹریفک صرف ایک لے جاتی ہے۔ scutil --proxy موجودہ بنیادی سروس کی قدریں چھاپتا ہے۔ پروفائل جیت گیا ہے یہ نتیجہ اخذ کرنے سے پہلے اس آؤٹ پٹ کا موازنہ اس سے کریں جو آپ نے ترمیم کیا تھا۔

ٹول کو اصل بالائی بہاؤ کی طرف موڑیں

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

یہی وہ قدم ہے جو آپ کو دوبارہ ترتیب دینے کے بجائے ڈیبگنگ میں رکھتا ہے۔

پراکسی کو ٹنل کے اندر دھکیلیں

OpenVPN پر مبنی کلائنٹ ایسے پراکسی اختیارات قبول کر سکتا ہے جو ٹنل کھڑا ہونے کے بعد لاگو ہوتے ہیں، جو اس وقت آسان ہے جب راستے کلائنٹ کے پاس ہوں:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

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

کچھ کلائنٹ سسٹم پراکسی کبھی نہیں پڑھتے

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

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

کنفیگریشن پڑھیں، ٹوگل نہیں

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

یہاں ہر معاملہ کنفیگریشن ترجیح کا مسئلہ ہے۔ کوئی بھی ٹنل آپ کا ٹول تباہ نہیں کر رہا۔