mitmproxy، DevTools، Gradle: VPN کے پیچھے تین تہیں
loopback کبھی سرنگ میں داخل نہیں ہوتا۔ علامت کو سننے والا، اعتماد کا ذخیرہ یا پیکٹ فلٹر کے طور پر درجہ بند کریں اور وہ تہہ درست کریں جو واقعی ناکام ہوئی۔
VPN جڑتا ہے، اور تین غیر متعلقہ اوزار تین مختلف طریقوں سے ناکام ہوتے ہیں اسی دوپہر۔ mitmproxy درخواستیں دیکھنا بند کر دیتا ہے، Chrome ڈیبگر سے انکار کرتا ہے، اور Gradle BindException مقامی ساکٹ باندھتے وقت پھینکتا ہے۔ مشترکہ شبہ یہ ہے کہ سرنگ localhost کو روکتی ہے۔ یہ ایسا نہیں کر سکتی: 127.0.0.1 کرنل کے اندر سنبھالا جاتا ہے اور کبھی اڈاپٹر تک نہیں پہنچتا، گیٹ وے کی تو بات ہی چھوڑیں۔
تین تہیں، تین مختلف خرابیاں
کلائنٹ کے ساتھ جو بدلا وہ loopback کا راستہ نہیں ہے۔ وہ مقامی پراکسی، مشین کا اعتماد کا ذخیرہ اور پیکٹ فلٹر ہیں، اور ہر ایک ڈویلپر کے کام کے بہاؤ کا الگ حصہ توڑتا ہے۔ علامت کو صحیح قطار میں رکھنا ہی تشخیص کا بڑا حصہ ہے:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
اس قسم کی تقریباً ہر رپورٹ آخری قطار سے شروع ہو کر اوپر جاتی ہے، جو الٹا ہے۔ سرنگ ہی وہ واحد تہہ ہے جو ثابت شدہ طور پر loopback ٹریفک نہیں دیکھ سکتی، اس لیے اسے سب سے کم شبہ ملنا چاہیے۔ اس بات سے شروع کریں کہ عمل نے کیا باندھا، پھر پوچھیں کہ وہ کن سرٹیفکیٹس پر بھروسہ کرتا ہے، اور اس کے بعد ہی مشین پر پالیسی دیکھیں۔
سرنگ سے نہیں، سننے والے سے شروع کریں
جب 127.0.0.1:8080 پر کوئی پراکسی ٹریفک لینا بند کر دے، تو تین میں سے ایک ہوا: وہ کبھی شروع نہیں ہوا، اس نے دوسرا پورٹ باندھا، یا فلٹر نے loopback کنکشن گرا دیا۔ سننے والے ساکٹ کی فہرست ایک ہی کمانڈ میں جواب دیتی ہے، اور یہ بھی دکھاتی ہے کہ کون سا عمل پورٹ کا مالک ہے جب دو اوزار اس پر متفق نہ ہوں کہ پہلے کون تھا۔
روٹ تلاش میں مقامی پتہ دوسری طرف سے یہی بات تصدیق کرتا ہے۔ ip route get loopback منزل کی طرف یہ loopback ڈیوائس کی اطلاع دیتا ہے، سرنگ کی کبھی نہیں، اور جب کوئی حل کے طور پر روٹنگ تبدیلی تجویز کرے تو یہ ایک مفید جملہ ہے جو تیار رکھنا چاہیے۔
پراکسی تہہ: ماحول ترتیب نہیں ہے
بہت سے کارپوریٹ کلائنٹ HTTP پراکسی چلاتے ہیں اور توقع کرتے ہیں کہ ایپلیکیشنز اسے استعمال کریں گی۔ سیٹ کرنا HTTPS_PROXY شیل میں اس کا احترام کرنے والے کمانڈ لائن اوزار درست کرتا ہے، اور اپنی سیٹنگز فائل پڑھنے والے اوزار کے لیے کچھ نہیں کرتا۔ Gradle، Selenium اور gRPC میں سے ہر ایک اپنی ترتیب سے مشورہ کرتا ہے، اور ایک ٹرمینل میں برآمد کردہ پراکسی IDE کے شروع کردہ ڈیمن کے لیے پوشیدہ ہے۔
کنٹینر اوزار عام طور پر وہ جگہ ہیں جہاں یہ ظاہر ہوتا ہے۔ کنٹینر کا loopback اس کا اپنا ہوتا ہے، اس لیے 127.0.0.1 کنٹینر کے اندر کبھی میزبان کی پراکسی کا مطلب نہیں ہوتا؛ میزبان کا پتہ یا میزبان نیٹ ورک کی ترتیب درکار ہے۔ جو حل شیل میں کام کرتا ہے اور بلڈ میں ناکام ہوتا ہے وہ عام طور پر یہی قطار ہے، سرنگ نہیں۔
اعتماد کی تہہ: اوزار دوسرا ذخیرہ پڑھتا ہے
مداخلت دوسری تبدیلی ہے، اور یہ سب سے گمراہ کن غلطیاں پیدا کرتی ہے۔ کلائنٹ جانچے گئے کنکشنز کے لیے اپنا سرٹیفکیٹ پیش کرتا ہے، اس لیے کارپوریٹ جڑ پر بھروسہ کرنے والا براؤزر کامیاب ہوتا ہے جبکہ شامل CA ذخیرے والا اوزار ناکام ہوتا ہے۔ certifi کے ذریعے Python requests کلاسیک مثال ہے: آپریٹنگ سسٹم کا ذخیرہ درست ہو سکتا ہے اور درخواست پھر بھی ناکام ہوتی ہے، کیونکہ وہ رن ٹائم اسے کبھی نہیں پڑھتا۔ غلطی کے متن میں مداخلت کا ذکر شاذ و نادر ہی ہوتا ہے، اسی لیے اس قطار کی تشخیص غلط طور پر ٹوٹے اینڈ پوائنٹ کے طور پر کی جاتی ہے۔
اینڈ پوائنٹ واقعی کیا پیش کرتا ہے اس کا موازنہ اس سے کریں جو اوزار نے تصدیق کیا۔ openssl s_client سرور کی بھیجی ہوئی زنجیر دکھاتا ہے؛ اوزار کا اپنا تصدیقی آؤٹ پٹ دکھاتا ہے کہ اس نے کیا فیصلہ کیا۔ جب وہ مطابقت نہیں رکھتے، REQUESTS_CA_BUNDLE یا SSL_CERT_FILE اس رن ٹائم کے لیے لیور ہے، اور کارپوریٹ جڑ اس ذخیرے میں ہونی چاہیے جو وہ رن ٹائم پڑھتا ہے، نہ کہ ایسی عالمی جگہ میں جسے صرف چند اوزار مانتے ہیں۔
SSL غلطی درست کرنے والی ورژن تبدیلی VPN کے بارے میں نہیں، اعتماد اور سائفر پالیسی کے بارے میں ثبوت ہے۔ SOAP کلائنٹ کو چلانے والی Python کی ڈاؤن گریڈ نے شامل CA ذخیرہ اور طے شدہ TLS ترتیبات بدل دیں؛ نیٹ ورک راستہ نہیں ہلا۔
فلٹر تہہ: یہ loopback بھی گرا سکتی ہے
تیسری تبدیلی پیکٹ فلٹر ہے، اور کچھ مصنوعات ایسے قواعد نصب کرتی ہیں جو سرنگ میں نہ آنے والا ٹریفک گرا دیتے ہیں۔ مقامی سننے والے بھی شامل ہو سکتے ہیں۔ یہ کام کرتے ساکٹ کو مسترد یا وقت گزرا کنکشن بنا دیتا ہے، اور نتیجے میں غلطی مشین پر پالیسی کے بجائے ایپلیکیشن میں خرابی جیسی لگتی ہے۔
پورٹ کی ملکیت اس تہہ کا دوسرا نصف ہے۔ BindException کا مطلب ہے کہ ساکٹ کھولا نہیں جا سکا، جو کنکشن مسترد ہونے سے مختلف ناکامی ہے۔ فلٹر کو الزام دینے سے پہلے دیکھیں کہ کوئی دوسرا عمل پورٹ رکھتا ہے یا نہیں، پھر ایسا قاعدہ تلاش کریں جو مقامی ٹریفک گرا دے اور مصنوعات کی حمایت کردہ تنگ ترین اجازت شامل کریں۔ ایک ہی ڈیبگ پورٹ کے لیے مقابلہ کرنے والے دو اوزار پالیسی بلاک جیسا ہی پیغام دیتے ہیں، اور ان میں سے صرف ایک فائر وال تبدیلی سے درست ہوتا ہے۔
Chrome کا ڈیبگ پورٹ اسی خاندان میں ناکام ہوتا ہے۔ براؤزر شروع ہوتا ہے، ڈرائیور DevTools اینڈ پوائنٹ تک نہیں پہنچ سکتا، اور پیغام نیٹ ورک کے بجائے DevTools کا نام لیتا ہے۔ اضافی لانچ فلگز اور غیر ضروری ڈرائیور مینیجر بدلتے ہیں کہ کون سا عمل پورٹ کا مالک ہے، اسی لیے انہیں ہٹانا کبھی کبھی VPN درست کرنے جیسا لگتا ہے۔
جس تہہ نے ناکامی دی اسے درست کریں
سرنگ کو نہیں، جس تہہ نے ناکامی دی اسے درست کریں۔ ناقابل رسائی loopback سننے والے کے سننے والے یا پورٹ کو درست کرنا ہوگا۔ ناقابل اعتماد سرٹیفکیٹ کے لیے کارپوریٹ جڑ وہیں نصب ہونی چاہیے جہاں وہ مخصوص رن ٹائم دیکھتا ہے، استثنا تنگ رکھتے ہوئے۔ مقامی ٹریفک گرانے والے فلٹر کے لیے بند فلٹر کے بجائے مخصوص اجازت قاعدہ درکار ہے، کیونکہ بند کرنا وہ سب کچھ بھی دوبارہ کھول دیتا ہے جس کی وہ حفاظت کر رہا تھا۔
VPN کو دوبارہ جوڑنا ان میں سے کسی تہہ کی جانچ نہیں کرتا۔ یہ صرف وہی تبدیلی دوبارہ چلاتا ہے جس نے انہیں توڑا تھا، اسی لیے وہی تین ناکامیاں ہر دوبارہ جوڑنے کے بعد لوٹ آتی ہیں اور کلائنٹ کو غیر فعال چھوڑنے والے ہر ری بوٹ کے بعد غائب ہو جاتی ہیں۔