Docker کی pool اوورلیپ خرابی VPN روٹ کا مسئلہ نہیں

Docker اس پتہ جگہ میں pool کے کسی دوسرے سے اوورلیپ ہونے کے پیغام کے ساتھ نیٹ ورک بنانے سے انکار کرتا ہے، اور کوئی فیصلہ کرتا ہے کہ VPN روٹ ہی وجہ ہونی چاہیے۔ ایسا نہیں ہو سکتا۔ وہ خرابی اس وقت پیدا ہوتی ہے جب pool تقسیم ہو رہا ہو، ایک پیکٹ بھی موجود ہونے سے پہلے، اور ہاتھ سے بنایا گیا کرنل روٹ اس پر کوئی اثر نہیں ڈالتا۔ VPN ایک قدم بعد اہم ہوتا ہے، جب پہلے سے پتہ رکھنے والا کنٹینر کسی روٹ کے ظاہر ہونے کے بعد ناقابل رسائی ہو جاتا ہے۔ دو مسائل، شہادتوں کے دو مجموعے، اور انہیں ملانا ایسی تبدیلی پیدا کرتا ہے جو کسی کو بھی درست نہیں کرتا۔

ایک جیسی نظر آنے والی دو خرابیاں

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

رن ٹائم علامت رسائی کا سوال ہے۔ کل جواب دینے والا کنٹینر اب جواب نہیں دیتا، اور ہوسٹ کی روٹنگ جدول میں کچھ بدل گیا ہے۔ کنٹینر اب بھی اپنا پتہ رکھے ہوئے ہے؛ سوال یہ ہے کہ وہ پتہ کون سا راستہ لیتا ہے۔

دونوں پتہ منصوبے کے مسائل ہیں۔ ان میں سے صرف ایک Docker کا مسئلہ ہے۔

پہلے تقسیم شدہ pool پڑھیں

نیٹ ورک کی فہرست بنائیں اور انہیں جانچیں جو تقاطع کر سکتے ہیں۔ ذیلی نیٹ IPAM ترتیب میں رہتا ہے، اور منسلک کنٹینر الگ سے درج ہوتے ہیں:

docker network ls
docker network inspect EXISTING_NETWORK

اس ذیلی نیٹ کا موازنہ نئے نیٹ ورک کے مانگے ہوئے pool سے کریں، اور یاد رکھیں کہ Compose ہر منصوبے کے لیے اپنا ڈیفالٹ نیٹ ورک بناتا ہے۔ بھولے ہوئے منصوبے سے تصادم ڈیمون سے تصادم جیسا ہی دکھتا ہے۔

کسی سروس پر مستقل ipv4_address ایک کنٹینر کا پتہ ہے، pool کی تعریف نہیں۔ اسے بدلنے سے اوورلیپ نہیں جاتا، کیونکہ اوورلیپ نیٹ ورک ذیلی نیٹوں کے درمیان ہوتا ہے، کنٹینروں کے درمیان نہیں۔ Docker کا network-create حوالہ عام برج تقسیم کے لیے غیر اوورلیپنگ ذیلی نیٹ مانگتا ہے اور دستاویز کرتا ہے کہ ایک کو واضح طور پر کیسے منتخب کیا جائے۔

VPN سے بچنے والا سابقہ منتخب کریں

فوری تصادم اور مستقبل کا روٹ ایک ہی انتخاب سے طے ہوتے ہیں، اس لیے یہ ایک بار کریں۔ امیدوار رینج کا موازنہ LAN، ہوسٹ کی پہنچ میں آنے والی ہر VPN منزل، اور استعمال میں کسی بھی دوسرے overlay سے کریں۔

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

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

نیٹ ورک کو جان بوجھ کر ہٹائیں یا بدلیں

نئے Compose نیٹ ورک کے لیے، نیٹ ورک کی IPAM ترتیب میں غیر استعمال شدہ سابقہ مقرر کریں۔ موجودہ منصوبے کے لیے، دوبارہ نمبر کاری کی منصوبہ بندی کریں: مستقل پتے، منحصر خدمات اور نیٹ ورک دوبارہ بنانے کا مرحلہ—سب کو مدنظر رکھنا ہوگا، کیونکہ YAML میں ترمیم چلتے نیٹ ورک کو دوبارہ نمبر نہیں کرتی۔

اگر کوئی پرانا نیٹ ورک متصادم تقسیم کا مالک ہے، تو اسے ہٹانے سے پہلے دیکھیں کون منسلک ہے۔ docker network rm فعال endpoint موجود ہونے تک انکار کرتا ہے، اور docker stop نیٹ ورک کے نام کی بجائے کنٹینر کے نام یا ID لیتا ہے۔ کنٹینر روکنے سے pool رکھنے والی نیٹ ورک تعریف بھی نہیں ہٹتی۔

وسیع prune تشخیص کا ذریعہ نہیں۔ یہ غیر متعلقہ منصوبوں تک پہنچتا ہے اور وہ شہادتیں تباہ کرتا ہے جو آپ جمع کرنے والے تھے۔

ڈیفالٹ pool صرف اگلی تقسیم میں مدد کرتے ہیں

ڈیمون کی ڈیفالٹ پتہ pool ترتیب مستقبل کی خودکار تقسیموں کو آپ کے محفوظ کردہ رینج سے باہر رکھ کر بہتر بناتی ہے۔ یہ پہلے سے موجود نیٹ ورکس کو ماضی کی طرف جا کر نئے پتے نہیں دیتی، اور دوسرے واضح ذیلی نیٹ سے اوورلیپ ہونے والے واضح ذیلی نیٹ کا حل نہیں کرتی۔

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

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

کام کی ترتیب: تقسیم شدہ pool پڑھیں، ایسا سابقہ منتخب کریں جو Docker اور VPN منزلوں دونوں سے بچے، نیٹ ورک کو جان بوجھ کر دوبارہ بنائیں، پھر ٹنل کے اوپر ہونے کی حالت میں ایک درخواست جانچیں۔