Proxmox پر LXC یا VM میں WireGuard: یہ کہاں چلنا چاہیے؟
WireGuard Proxmox میزبان پر، کنٹینر میں یا VM میں چل سکتا ہے۔ فیصلہ کن عوامل کرنل کی ملکیت، انٹرفیس کا کنٹرول اور بحالی ہیں۔
WireGuard کو اپنے انٹرفیس کا مالک بننے کے لیے ٹھیک ایک کرنل درکار ہے، اور یہ حقیقت کارکردگی کے بحث میں آنے سے پہلے ہی Proxmox پر جگہ کے انتخاب کا بیشتر تنازع طے کر دیتی ہے۔ LXC کنٹینر میزبان کرنل کے نام کی جگہ کا ایک منظر ہے، جبکہ VM اپنا کرنل بوٹ کرتا ہے۔ چنانچہ مفید سوال یہ نہیں کہ کون سا آپشن ہلکا ہے، بلکہ یہ ہے کہ آپ کون سا کرنل بدلنے کو تیار ہیں اور کس بحالی راستے کے ساتھ جی سکتے ہیں۔ اس کا جواب دیں، اور میزبان، کنٹینر یا VM کا انتخاب عموماً خود بخود ہو جاتا ہے۔
LXC مہمان میزبان کرنل کے اندر کام کرتا ہے
کنٹینر کے اندر wireguard-tools نصب کرنے سے آپ کو کنٹرول پروگرام ملتا ہے، نجی کرنل نہیں۔ آپ جو wg0 انٹرفیس بناتے ہیں وہ میزبان کے نیٹ ورک اسٹیک میں درج ہوتا ہے اور میزبان کی ماڈیول فہرست میں ظاہر ہوتا ہے۔ اسی لیے کنٹینر ہر پیکیج جانچ پاس کر سکتا ہے اور پھر بھی پہلی wg کمانڈ پر ناکام ہو سکتا ہے، جب میزبان کرنل میں وہ ماڈیول نہ ہو۔ اور Proxmox کنٹینر ریفرنس اس مشترکہ کرنل ماڈل کی، نیز ان نام کی جگہ اور استحقاق کی حدوں کی دستاویز کرتا ہے جن کے اندر آپ کام کرتے ہیں۔
اختیار دوسری رکاوٹ ہے۔ انٹرفیس اوپر اٹھانے اور اس پر پتے جوڑنے کے لیے اس نام کی جگہ کے اندر نیٹ ورک انتظامی حقوق درکار ہیں جو اس کا مالک ہے، اور غیر مراعات یافتہ کنٹینر ان حقوق کو براہ راست رکھنے کے بجائے اپنے صارف نام کی جگہ کے ذریعے نقش کرتا ہے۔ پہلے جواب کے طور پر کبھی مکمل استحقاق کی طرف نہ بڑھیں؛ دیکھیں کہ کنٹینر سے واقعی کیا مانگا جا رہا ہے، پھر وہی دیں۔
میزبان کرنل بھی مشترکہ انحصار ہے۔ Proxmox کرنل کی تازہ کاری ہر کنٹینر کے نیچے WireGuard کے نفاذ کو ایک ساتھ بدل دیتی ہے، جو اس وقت تک سہولت بخش ہے جب تک کوئی تازہ کاری اور کسی کنٹینر کی توقعات میں اتفاق نہ رہے۔
میزبان، کنٹینر، VM: ہر جگہ کا انتخاب واقعی کیا رکھتا ہے
میزبان پر انتخاب VPN کو ہائپر وائزر کے اپنے نیٹ ورک میں رکھتا ہے۔ راستے، فائر وال کے قواعد اور سرنگ میزبان کی بحالی کا حصہ بن جاتے ہیں، اور وہاں کی غلطی انتظامی انٹرفیس کو بھی لے سکتی ہے۔ کنسول کے ذریعے پہنچنے والے میزبان پر بنیادی ڈھانچے کی راستہ بندی کے لیے یہ قابل قبول ہے، اور بینڈ سے باہر رسائی کے بغیر دور مشین پر تکلیف دہ۔
کنٹینر سروس کو پیکیج شدہ اور دوبارہ شروع کرنے کے قابل رکھتا ہے جبکہ پھر بھی میزبان کرنل ادھار لیتا ہے۔ یہ جان بوجھ کر مشترکہ کرنل والی سروس کے لیے موزوں ہے اور آپ کو دوبارہ تعمیر کے لیے چھوٹی اکائی دیتا ہے۔ یہ خودمختار کرنل نہیں دیتا، اس لیے جو بھی مخصوص ماڈیول بلڈ چاہتا ہے وہ اس آپشن سے دور اشارہ کرتا ہے۔
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM زیادہ میموری اور پیچ کرنے کے لیے ایک اور نظام خرچ کرتا ہے، اور بدلے میں سرنگ کو اپنا کرنل، اپنا روٹنگ جدول اور اسنیپ شاٹ کی حد ملتی ہے۔ جب خراب تبدیلی کے بعد VPN ہی وہ چیز ہو جسے آپ واپس لوٹاتے ہیں، تو وہ اسنیپ شاٹ اضافی بوجھ کے لائق ہے۔
تین شرطیں جو آپ کے لیے چنتی ہیں
اگر سرنگ کو کرنل کا ایسا ورژن یا WireGuard کی ایسی خصوصیت درکار ہو جو Proxmox میزبان فراہم نہیں کرتا، تو یہیں رکیں اور VM استعمال کریں۔ کنٹینر میں نیا کرنل نصب نہیں کیا جا سکتا، اور ایک مہمان کو خوش کرنے کے لیے ہائپر وائزر کرنل بدلنا نہیں چاہیے۔
اگر سرنگ حقیقی LAN سابقوں کے لیے سائٹ کا گیٹ وے ہے، تو پوچھیں کہ واپسی کے راستے کی ملکیت پہلے سے کس کے پاس ہے۔ کنٹینر ٹریفک کی راستہ بندی کر سکتا ہے، لیکن اس کے انٹرفیس میزبان کے اسٹیک میں بیٹھتے ہیں، اس لیے میزبان بالآخر ترتیب کا کچھ حصہ اٹھاتا ہے، خواہ آپ نے منصوبہ بنایا ہو یا نہیں۔ میزبان پر انتخاب اس معاملے میں دیانت دار ہے؛ کنٹینر میں انتخاب اکثر نہیں۔
پھر غلطی کے اثر کا دائرہ تولیں۔ کنٹینر دوبارہ شروع کرنا سستا ہے، VM اسنیپ شاٹ بحال کرنا قابل پیشین گوئی ہے، اور میزبان کی نیٹ ورکنگ درست کرنے کے لیے جسمانی یا کنسول رسائی درکار ہو سکتی ہے۔ درست انتخاب وہ ہے جس کا بدترین معاملہ آپ اسی گھنٹے میں واقعی بحال کر سکیں جب وہ پیش آئے۔
چوتھا سوال شاذ و نادر ہی فیصلہ کن ہوتا ہے لیکن قابل ذکر ہے: کیا میزبان پر کسی اور چیز کو سرنگ کا انٹرفیس دیکھنے کی ضرورت ہے؟ اگر ہاں، تو میزبان پر یا کنٹینر میں انتخاب اس دید کو مقامی رکھتا ہے، جبکہ VM آپ کو مہمان اور میزبان کے درمیان راستہ بندی پر مجبور کرتا ہے۔
ٹریفک کو اس سے گزرنے دینے سے پہلے انتخاب ثابت کریں
نصب ہونے کے بعد تصدیق کریں کہ واقعی کون سا کرنل انٹرفیس کو سروس دے رہا ہے اور کیا کنٹینر کو اسے رکھنے کے لیے کافی اختیار دیا گیا ہے:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0پھر میزبان سے فارورڈنگ کا رخ جانچیں، کیونکہ محض مصافحہ صرف یہ ثابت کرتا ہے کہ سرنگ کھڑی ہے۔ کلائنٹ پتے کے لیے ip route get استعمال کریں اور تصدیق کریں کہ اگلا قدم اور انٹرفیس ڈیزائن سے مطابقت رکھتے ہیں، اور دور کی طرف واپسی کا راستہ موجود ہے۔
تعیناتی کو تحریری مالک کے ساتھ چھوڑیں: کون سا کرنل نفاذ اٹھاتا ہے، کون سی نام کی جگہ انٹرفیس رکھتی ہے، اور گیٹ وے کو کون سے سابقے آگے بھیجنے کی اجازت ہے۔ وہ ایک جملہ تینوں انتخاب کے کسی بھی بینچ مارک موازنے سے زیادہ واقعات روکتا ہے۔