دو نیٹ ورکس والا کنٹینر غلط گیٹ وے منتخب کرتا ہے

آپ کا کنٹینر اب بھی اپنے کنٹرول برج پر جواب دیتا ہے، لیکن ہر باہر جانے والا پیکٹ دفتر کے macvlan سے باہر نکلتا ہے۔ کچھ ناکام نہیں ہوا۔ دو رابطے ہر ایک اپنا گیٹ وے دیتے ہیں، اور واحد ڈیفالٹ راستہ اس نیٹ ورک کی طرف گیا جو آپ کا مقصد نہیں تھا، اس لیے سروس کام کرتی رہتی ہے جبکہ اس کی ٹریفک لمبا راستہ لیتی ہے۔ جب کسی کو توجہ ہوتی ہے تو ثبوت غلطی کا پیغام نہیں بلکہ روٹنگ ٹیبل ہوتا ہے۔

عام وضاحت یہ ہے کہ Docker نے نیٹ ورک اتفاق سے چنا۔ عملی طور پر پرانا فیصلہ منسلک نیٹ ورک ناموں کی حروفِ تہجی ترتیب پر چلتا تھا، جس نے روٹنگ کو ایک لیبل کا ضمنی اثر بنا دیا۔ gw_priority اسے ایسے عدد سے بدلتا ہے جو آپ دانستہ منتخب کرتے ہیں، اور ترتیب لکھے جانے کے بعد اسے اپنانے میں تقریباً ایک منٹ لگتا ہے۔

ڈیفالٹ راستہ غلط نیٹ ورک پر کیوں گرتا ہے

ہر نیٹ ورک جس میں کوئی سروس شامل ہوتی ہے اپنا گیٹ وے پیش کر سکتا ہے، پھر بھی کنٹینر کے پاس ٹھیک ایک ہی ڈیفالٹ راستہ رہتا ہے۔ Compose 2.33.1 سے پہلے برابری نیٹ ورک ناموں کو ترتیب دے کر طے ہوتی تھی، اس لیے control جیسا لیبل جو office سے پہلے آتا ہے، یہ طے کرتا تھا کہ ٹریفک کہاں جائے گی۔ کنٹینر کے اندر کوئی چیز درج نہیں کرتی کہ فیصلہ من مانی تھا، اسی لیے یہ کوڈ جائزے سے گزر جاتا ہے اور بعد میں عجیب راستے کے طور پر سامنے آتا ہے۔ compose فائل میں پالیسی رکھنا ہی اس انتخاب کو قابلِ جانچ بنانے کا واحد طریقہ ہے۔

کون سا نیٹ ورک جیتے گا یہ واقعی دو چیزیں بدلتی ہیں: آپ کے مقرر کردہ gw_priority اقدار، اور یہ کہ کون سے نیٹ ورک منسلک ہیں۔ تیسرا نیٹ ورک شامل کریں تو امیدواروں کا مجموعہ بڑھتا ہے؛ macvlan ہٹا دیں تو پل سے مقابلہ کرنے کو کچھ نہیں بچتا۔ دونوں میں سے کوئی قدم ایپلیکیشن لاگز میں نظر نہیں آتا، کیونکہ غلط ڈیفالٹ راستہ شاذ و نادر ہی رابطہ مکمل طور پر توڑتا ہے۔ یہ صرف جوابات کو ایسے پتے سے آنے دیتا ہے جس کی دوسری طرف شاید توقع نہ ہو۔

gw_priority سے گیٹ وے مقفل کریں

Compose 2.33.1 ورژن سے ہر سروس سے نیٹ ورک رابطے پر gw_priority ظاہر کرتا ہے، اور سب سے بڑا عدد جیتتا ہے۔ فی سروس الگ گیٹ وے کلید نہیں ہے، اس لیے قدر سروس کے networks بلاک میں آتی ہے۔ نیچے کی مثال ڈیفالٹ control کو دیتی ہے جبکہ office اپنے براہِ راست منسلک LAN کے لیے قابلِ رسائی رہتا ہے۔

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

بلاک کو دو الگ کنٹرول سمجھیں: gw_priority ڈیفالٹ راستہ طے کرتا ہے، اور ipam حصہ پتہ طے کرتا ہے۔ صرف subnet بدلنے سے اخراج کا انتخاب اچھوتا رہتا ہے، اور یہی اس اصلاح کے آدھا لاگو ہونے کا عام ترین طریقہ ہے۔ ترجیحات کو اسی نیٹ ورک کے پاس رکھیں جس پر وہ حکمرانی کرتی ہیں تاکہ اگلے قاری کو فیصلہ ڈھونڈنا نہ پڑے۔

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

تصدیق کریں کہ درحقیقت کون سا نیٹ ورک ڈیفالٹ راستہ اٹھاتا ہے

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

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

درست نتیجہ پل کے آلے اور 172.30.50.1 کا نام لیتا ہے؛ غلط نتیجہ 192.168.120.1 اور macvlan آلے کا۔ اگر امیج میں iproute2 پیکیج نہ ہو تو /proc فائل پھر بھی ڈیفالٹ راستہ بتاتی ہے، منزل 00000000 اور گیٹ وے کے بائٹ الٹے ہوئے۔ جب آلات کے نام واضح نہ ہوں تو انٹرفیس کالم کا docker inspect سے موازنہ کریں۔

macvlan ایک جسمانی پورٹ ہے، پل کی نقل نہیں

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

macvlan_mode: bridge ترتیب macvlan ڈرائیور کا ایک موڈ ہے، Docker کا سافٹ ویئر پل نہیں، اور passthru ڈیفالٹ نہیں بلکہ الگ خصوصی موڈ ہے۔ Linux macvlan کنٹینر کو اس کے اپنے میزبان تک پہنچنے سے بھی روکتا ہے اسی والد کے ذریعے، اور اسی لیے کنٹرول پل رکھا جاتا ہے، ایک رابطہ دونوں کام کرے گا اس توقع کے بجائے۔

Compose کے دیکھنے سے پہلے VLAN والد کا نام رکھیں

Docker eno1.120 جیسے نقطے والے والد کو 802.1Q ذیلی انٹرفیس سمجھتا ہے اور VLAN آلہ خود بناتا ہے۔ اس سہولت کی حدیں ہیں: ماخوذ نام جسمانی انٹرفیس کے نام پر منحصر ہے، اور لمبے نام نتیجہ کو گرد و نواح کے اوزار کی توقعات سے آگے دھکیل سکتے ہیں۔ میزبان کی نیٹ ورک کنفیگ میں نام رکھا VLAN انٹرفیس بنا کر parent کو اس کی طرف اشارہ کرنا دونوں سروں کو قابلِ اندازہ رکھتا ہے۔

یاد رکھیں کہ networks کے تحت کلید Compose نام ہے، Linux آلہ نہیں۔ میزبان پر office نامی انٹرفیس تلاش کرنا ناکام ہوگا، کیونکہ کرنل صرف والد انٹرفیس اور کنٹینر کے پیچھے veth جوڑی دیکھتا ہے۔

اوپر VPN کے لیے جگہ بنائیں

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

VPN شروع ہونے کے بعد اور دوبارہ جڑنے کے بعد بھی پتے، راستے اور سروس کا راستہ دوبارہ جانچیں، کیونکہ ہاتھ سے شامل کیا گیا راستہ دوبارہ جڑنے کے موقع ہی پر غائب ہوتا ہے۔ پہلے امتحان سے پہلے متوقع ٹیبل لکھ لیں تاکہ بعد کا موازنہ یادداشت کی مشق نہیں بلکہ diff ہو۔ نیٹ ورک کی مستقل ملکیت Compose میں رکھیں اور VPN کنفیگ کو صرف اپنی پالیسی رکھنے دیں۔