VPN کنٹینر کا نیٹ ورک شیئر کرنا: DNS کے ساتھ کیا ہوتا ہے

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

مرحلہ 1: ہوسٹ سے نہیں، ایپ سے جانچیں

جس کنٹینر میں مسئلہ ہے اس کے اندر لک اپ چلائیں، ہوسٹ پر نہیں اور براؤزر میں نہیں۔ docker exec app-container getent hosts db.internal واحد اہم سوال کا جواب دیتا ہے: اس عمل کا ریزولور کیا واپس کرتا ہے۔

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

مرحلہ 2: رن ٹائم کا تعاون یافتہ ماڈل پڑھیں

Docker کی نیٹ ورک دستاویزات دوسرے کنٹینر کا نیٹ ورک موڈ شیئر کرنے والے کنٹینرز کے لیے DNS جھنڈیوں پر پابندیاں درج کرتی ہیں۔ Compose میں network_mode: service:vpn ایپ کو VPN کنٹینر کے نیم اسپیس سے باندھتا ہے، اور ہر سروس کے لیے dns ترتیبات عام سروس کی طرح برتاؤ نہیں کرتیں۔ آپ کو ملنے والا حل وہی ہے جو مشترکہ نیم اسپیس کے پاس ہے۔

صارف کی متعین بریج نیٹ ورک بھی Docker کے اندرونی DNS کو ڈیفالٹ بریج سے مختلف طریقے سے استعمال کرتے ہیں۔ اسی لیے dns کام کرنے والی بریج مثال سے نقل کیا گیا شق مشترکہ اسٹیک میں کچھ بھی نہیں کر سکتا۔ شق نقل کرنے سے پہلے ترتیب جانچیں۔

لوپ بیک پتہ ہمیشہ متعلقہ نیٹ ورک سیاق و سباق کی طرف اشارہ کرتا ہے۔ مشترکہ نیم اسپیس کے اندر، 127.0.0.1 ہوسٹ کا ریزولور نہیں ہے۔

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

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

براؤزر کا IP جانچ صفحہ نہیں بتا سکتا کہ نام کے استفسارات کہاں گئے۔ یہ بتاتا ہے کہ ایک HTTP کنکشن کہاں گیا۔

مرحلہ 4: دو ناکامی کی اقسام کو الگ الگ ٹھیک کریں

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

اگر دونوں اقسام ناکام ہوں، ریزولور تک رسائی سے شروع کریں۔ اگر صرف ایک ناکام ہو، دریافت کے طریقہ کار سے شروع کریں۔ دونوں کے مالک الگ ہیں، اس لیے ایک مرمت کبھی دونوں کو نہیں ڈھکتی۔

مرحلہ 5: دوبارہ بنانے کے بعد دوبارہ جانچیں

رن ٹائم کے تعاون یافتہ طریقہ کار سے ترتیب بدلیں، پھر چل رہے کنٹینر کے اندر فائلیں ترمیم کرنے کے بجائے کنٹینر دوبارہ بنائیں۔ نیا نجی نام، نیا عوامی نام اور لک اپ کے بعد آنے والی ایپلیکیشن درخواست جانچیں۔ /etc/resolv.conf کنٹینر کے اندر کی ترمیم دوبارہ بنانے پر غائب ہو جاتی ہے اور آپ کو یقین دلاتی ہے کہ مرمت ہو گئی جبکہ نہیں ہوئی۔

مشترکہ نیٹ ورک تعریف کے پاس ریزولور کا مالک اور متوقع نیم اسپیس لکھیں۔ اگلے شخص کو دونوں کی ضرورت ہوگی۔