کیوں ایک macvlan کنٹینر VPN کلائنٹ کو جواب نہیں دے سکتا

ایک Linux میزبان کا تصور کریں جو VPN ختم کرتا ہے اور ساتھ ہی macvlan نیٹ ورک پر کنٹینر چلاتا ہے۔ LAN 192.168.60.0/24 ہے، کنٹینر کے پاس 192.168.60.210 ہے، اور VPN کلائنٹ 10.95.0.0/24 سے آتے ہیں۔ کلائنٹ سروس تک پہنچتا ہے، جواب کبھی واپس نہیں آتا، اور میزبان پر ہر فائر وال قاعدہ درست دکھائی دیتا ہے۔ یہ علامت دو الگ الگ پابندیاں پیدا کرتی ہیں، اور ایک کو ٹھیک کرنے سے دوسری اپنی جگہ پر رہتی ہے۔

دو پابندیاں، ایک علامت

پہلی پابندی علیحدگی ہے: Docker کا macvlan ڈرائیور کنٹینر کو والدانی انٹرفیس کے ذریعے اپنے ہی میزبان سے بات کرنے کی اجازت نہیں دیتا۔ میزبان اسٹیک اور کنٹینر کے درمیان ٹریفک کا کوئی راستہ نہیں، میزبان پر راستے کیسے بھی لکھے گئے ہوں۔

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

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

میزبان کی طرف کا shim تنگ انداز میں بنائیں

میزبان پر دوسرا macvlan انٹرفیس، جو اسی والدانی انٹرفیس سے پل موڈ میں جڑا ہو، میزبان اسٹیک کو اس LAN حصے پر اپنی شناخت دیتا ہے۔ اس کے لیے DHCP پول سے باہر اور کنٹینر کی حد سے باہر پتہ مختص رکھیں، اور صرف کنٹینر کو اس سے گزاریں۔

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

پہلا حکم انٹرفیس کو پل موڈ میں بناتا ہے، جو اس ڈرائیور کے لیے دستاویزی ڈیفالٹ ہے اور میزبان و کنٹینر ٹریفک کے لیے مطلوبہ موڈ ہے۔ دوسرا /32 تفویض کرتا ہے تاکہ پتہ LAN سابقہ سے نہ ٹکرائے، اور چوتھا shim کے ذریعے صرف کنٹینر کا پتہ بھیجتا ہے۔

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

یہ حکم چلتے میزبان پر نیٹ ورک کی ترتیبات بدلتے ہیں۔ کسی آلے یا زیر انتظام پلیٹ فارم پر اس پلیٹ فارم کی معاون ترتیب کا طریقہ استعمال کریں، کیونکہ root-shell میں کیا گیا تعاملی تبدیلی اپ گریڈ کے بعد نہ رہ سکے۔

فیصلہ کریں کہ ماخذ کیسے محفوظ رہے گا

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

یہ کام کرنے کے لیے کنٹینر کی نیٹ ورک ترتیب کو اس راستے کے لیے 10.95.0.0/24 کی ٹریفک 192.168.60.250 پر اپنے گیٹ وے کے طور پر بھیجنا ہوگا۔ یہ کنٹینر کی اپنی ترتیب کے اندر معاون راستہ یا گیٹ وے کی ترتیب ہے، میزبان کی طرف کی کوئی ترکیب نہیں۔ ترتیب لاگو ہو گئی فرض کرنے کے بجائے کنٹینر کے اندر سے اس کی تصدیق کریں۔ جو ڈیفالٹ گیٹ وے ابھی بھی LAN راؤٹر کی طرف اشارہ کرتا ہے وہ جوابات اسی سوراخ میں بھیجتا رہے گا۔

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

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

کلائنٹ سے تصدیق کریں، میزبان سے نہیں

میزبان ہی سے shim کے پتے پر بندھی درخواست ثابت کرتی ہے کہ shim کنٹینر تک پہنچ سکتا ہے۔ لیکن یہ ثابت نہیں کرتی کہ کنٹینر محفوظ 10.95.0.x ماخذ کی طرف ٹریفک واپس بھیج سکتا ہے، کیونکہ اس امتحان میں ماخذ پتہ shim کا اپنا ہے۔

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

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