Docker کنٹینرز کی ٹریفک میزبان کے VPN کو نظرانداز کرتی ہے: کیسے جانچیں
میزبان کا VPN صرف میزبان کے نیٹ ورک نام فضا کو محیط ہے۔ ان جانچوں سے معلوم کریں کہ پل پر موجود کنٹینرز کی ٹریفک سرنگ میں داخل ہوتی ہے یا سیدھی باہر جاتی ہے۔
میزبان پر آپ کا براؤزر VPN کا اخراجی پتہ دکھاتا ہے، کنٹینر آپ کے گھریلو کنکشن کی اطلاع دیتا ہے، اور کوئی اسے رساؤ کہتا ہے۔ کچھ رسا نہیں۔ میزبان کی سرنگ انٹرفیس، راستوں اور قواعد کا مجموعہ ہے جو میزبان کی نیٹ ورک نام فضا سے تعلق رکھتے ہیں، اور پل پر موجود کنٹینر اپنے طے شدہ راستے والی دوسری نام فضا ہے۔ میں ایسے Compose اسٹیک پر بیٹھا ہوں جہاں VPN کلائنٹ ہفتوں سے منسلک تھا اور ایک بھی کنٹینر پیکٹ کبھی اس میں داخل نہیں ہوا۔
ٹرے آئیکن سے پہلے نام فضا جانچیں
نام فضائیں ہی پوری دلیل ہیں۔ جب Docker پل نیٹ ورک پر کنٹینر شروع کرتا ہے تو وہ نیٹ ورک نام فضا بناتا ہے، veth جوڑی کا ایک سرا اس کے اندر جوڑتا ہے، اور اس نام فضا کو پتہ اور طے شدہ راستہ دیتا ہے۔ سرنگ کا انٹرفیس، اسے جو بھی نام دیا جائے، میزبان کی نام فضا میں رہتا ہے۔ کنٹینر کے اندر کی ٹریفک اسے نہیں دیکھ سکتی، اور باہر سے کوئی کلائنٹ ترتیب اسے نہیں بدلتی۔
الگ تھلگ ہونے سے نکلنے کے دو معاون طریقے ہیں۔ --network host کنٹینر کو میزبان کی نام فضا کے اندر رکھتا ہے، اس لیے اسے میزبان کے راستے اور اسی طرح سرنگ ورثے میں ملتی ہے۔ --network container:vpn کسی دوسرے کنٹینر کی نام فضا شیئر کرتا ہے، اور زیادہ تر سائیڈ کار ڈیزائن ورک لوڈ کو VPN کنٹینر سے اسی طرح بھیجتے ہیں۔ دونوں واضح انتخاب ہیں؛ عام طور پر ان میں سے صرف ایک ہی وہ ہے جو تعینات کرنے والے کا مقصود تھا۔
میزبان موڈ مفت اپ گریڈ نہیں ہے۔ کنٹینر اپنا پتہ رکھنا چھوڑ دیتا ہے، پورٹ اشاعت لاگو نہیں رہتی، اور وہاں NET_ADMIN رکھنے والا عمل میزبان کی روٹنگ دوبارہ لکھ سکتا ہے۔ اسے قبول کرنا درست فیصلہ ہو سکتا ہے۔ اسے پہلے سے فعال سمجھنا ہی وہ وجہ ہے کہ لوگ ایک شام ایسی سرنگ کی خرابی دور کرنے میں گزارتے ہیں جو کبھی راستے میں نہیں تھی۔
پیکٹ کو پل سے باہر تک پیچھا کریں
پل کا کنٹینر اپنا پیکٹ اپنے طے شدہ گیٹ وے کو بھیجتا ہے، جو میزبان پر پل کا انٹرفیس ہے۔ پھر میزبان پیکٹ آگے بھیجتا ہے اور طے شدہ ترتیب میں پیکٹ کے باہر جانے سے پہلے ماخذ پتے کو اپنے پتے میں ترجمہ کرتا ہے۔ یہی ترجمے کا مرحلہ پالیسی کو خاموشی سے ہرا دیتا ہے۔
جب پیکٹ سرنگ کے آخری مقام تک پہنچتا ہے تو وہ میزبان کا پتہ اٹھائے ہوتا ہے۔ کنٹینر کے اصل پتے پر مبنی کوئی بھی قاعدہ، پالیسی راستہ یا منقسم سرنگ کا فیصلہ مماثلت کھو دیتا ہے، اور مختلف اخراجوں سے باہر جانے والے دو کنٹینرز کو صرف ماخذ سے الگ نہیں پہچانا جا سکتا۔ اگر آپ کو ہر کنٹینر کے لیے روٹنگ درکار ہے تو فیصلہ ترجمے سے پہلے یا آپ کے زیرِ کنٹرول نام فضا کے اندر ہونا چاہیے۔
Docker خود ان قواعد کو برقرار رکھتا ہے، اس فائر وال بیک اینڈ کے ذریعے جس سے ڈیمن تشکیل دیا گیا تھا۔ آگے بھیجی جانے والی ٹریفک کے لیے معاون ہک سے باہر ہاتھ سے لکھے گئے قواعد، DOCKER-USER، ڈیمن کے دوبارہ شروع ہونے یا میزبان کے اپ گریڈ ہونے پر دوبارہ ترتیب دیے جا سکتے ہیں یا ہٹائے جا سکتے ہیں۔ پیکٹ فلٹرنگ سے متعلق Docker کی دستاویز زنجیروں کی ترتیب دکھاتی ہے؛ عملی نکتہ یہ ہے کہ ہر قاعدے کو ایک مالک اور ایک دوبارہ لوڈ کا راستہ درکار ہے جسے آپ نے واقعی جانچا ہو۔
دونوں نظام الگ الگ جانچیں
ایک نام فضا کا ثبوت دوسرے کے بارے میں کچھ نہیں کہتا۔ VPN کنٹینر کے اندر چلائی گئی درخواست ثابت کرتی ہے کہ سرنگ اس کنٹینر کے لیے کام کرتی ہے۔ یہ میزبان کے بارے میں ثبوت نہیں، اور وہی حکم --network host کنٹینر سے چلانے پر پل کے بارے میں ثبوت نہیں۔
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'پھر جانچ کو ملتے جلتے امیج میں نہیں بلکہ اصل ایپلیکیشن کنٹینر کے اندر دہرائیں۔ ایپ میں اضافی راستہ، پراکسی ماحول متغیر یا مختلف حل کنندہ ہو سکتا ہے، اور ان میں سے ہر ایک جواب بدل دیتا ہے۔ ہر بار نام حل اور دوسرا پتہ خاندان جانچیں: صارف کی متعین کردہ پلوں پر کنٹینرز Docker کے بلٹ اِن حل کنندہ کے ذریعے 127.0.0.11 پر حل ہوتے ہیں، اور پل پر IPv6 طے شدہ راستہ ٹریفک باہر لے جا سکتا ہے جبکہ آپ صرف IPv4 سرنگ جانچنے میں مصروف ہوں۔
اسناد کو چھونے سے پہلے نمونہ پڑھیں
جب میزبان کام کرے اور کنٹینر نہ کرے تو وجہ تقریباً ہمیشہ ساختی ہوتی ہے، اور چابیاں بدلنا یا کلائنٹ دوبارہ نصب کرنا دوپہر ضائع کرتا ہے۔ پہلے علامت کو ترتیب دیں اور اصلاح عموماً خود اپنا نام بتا دیتی ہے۔
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
اوورلیپ کی سطر اپنا الگ جملہ مستحق ہے۔ 172.17.0.0/16 کے لیے، یا ایسے 10.0.0.0/8 کے لیے راستہ دھکیلنے والا VPN پروفائل جس میں آپ کے پل کا سابقہ اتفاقاً شامل ہو، سرنگ سے کنٹینر ذیلی نیٹ کا دعویٰ کروا دیتا ہے، اور ترجمہ شدہ پتوں کو جانے والے جوابات غلط سمت جائیں گے یا غائب ہو جائیں گے۔ Docker نیٹ ورک کو دوبارہ نمبر دینا عموماً استثناؤں کے جمع کرنے سے صاف تر ہے۔
کوریج کو واضح کریں، پھر اسے جان بوجھ کر توڑیں
دو ڈیزائن جائزے میں ٹک جاتے ہیں۔ VPN کنٹینر کی نام فضا شیئر کریں اور ہر محیط ورک لوڈ ایک ہی دوبارہ آغاز کی حد والی ایک سرنگ استعمال کرتا ہے، جو اس وقت تک سادہ ہے جب تک کسی سروس کو مختلف اخراج یا اپنا DNS راستہ درکار نہ ہو۔ یا کنٹینر نیٹ ورک کو میزبان پر VPN گیٹ وے کی طرف روٹ کریں: فارورڈنگ فعال، پل کا سابقہ سرنگ کی طرف، واپسی ٹریفک واضح طور پر سنبھالی گئی۔ یہ ہر نیٹ ورک کے لیے کنٹرول خریدتا ہے اور ڈیمن اور کلائنٹ اپ گریڈ کے دوران برقرار رکھنے والا قواعد کا مجموعہ آپ کو مہنگا پڑتا ہے۔
بہرحال، اہم جانچ ناکامی کی صورت ہے۔ کنٹینر کی درخواست ہوا میں ہوتے ہوئے سرنگ روکیں اور دیکھیں پیکٹ کہاں جاتا ہے۔ اگر وہ سیدھے راستے پر واپس گرے تو کوریج کبھی نافذ ہی نہیں ہوئی تھی، کیونکہ کلائنٹ کا kill switch خود کلائنٹ کی ٹریفک کنٹرول کرتا ہے، پل سے آگے بھیجے گئے پیکٹ نہیں۔ پھر ڈیمن اور میزبان دوبارہ شروع کریں اور نتیجہ دوسری بار تصدیق کریں؛ ہاتھ سے لکھے قواعد غائب ہونے کا لمحہ وہی ہے۔
اسے مکمل کہنے سے پہلے چار باتیں تصدیق کریں: سرنگ کا انٹرفیس ٹریفک جیسی ہی نام فضا میں ہے، کنٹینر جانچ اصل کنٹینر کے اندر ہوئی، نام حل اور دونوں پتہ خاندان جانچے گئے، اور سرنگ کی ناکامی کی جانچ اب بھی بند حالت میں ناکام ہوتی ہے۔ پھر فائر وال بیک اینڈ، کلائنٹ ورژن اور ہر قاعدے کا مالک لکھیں۔ وہی ریکارڈ اگلے اپ گریڈ کو پرانے مفروضوں کا غیر دستاویزی مرکب چھوڑنے سے روکتا ہے۔