WireGuard در LXC یا ماشین مجازی روی Proxmox: کجا باید اجرا شود؟
WireGuard می‌تواند روی هاست Proxmox، در یک کانتینر یا در یک ماشین مجازی اجرا شود. عوامل تعیین‌کننده مالکیت هسته، کنترل رابط و مسیر بازیابی هستند.
WireGuard به دقیقاً یک هسته نیاز دارد که مالک رابط آن باشد، و همین واقعیت بیشتر بحث مکان‌یابی روی Proxmox را پیش از آنکه کارایی وارد گفتگو شود حل میکند. کانتینر LXC نمایی از فضای نام هسته میزبان است، در حالی که ماشین مجازی هسته خود را بوت میکند. پس پرسش سودمند این نیست که کدام گزینه سبک‌تر است، بلکه این است که کدام هسته را حاضرید تغییر دهید و با کدام مسیر بازیابی می‌توانید زندگی کنید. به آن پاسخ دهید و انتخاب میان میزبان، کانتینر یا ماشین مجازی معمولاً خودش را تحمیل میکند.
مهمان LXC درون هسته میزبان کار میکند
نصب wireguard-tools درون یک کانتینر برنامه کنترل را به شما می‌دهد، نه یک هسته خصوصی. رابط wg0 که می‌سازید در پشته شبکه میزبان ثبت می‌شود و در فهرست ماژول‌های میزبان پدیدار می‌گردد. به همین دلیل کانتینر می‌تواند همه بررسی‌های بسته را بگذراند و با این حال در نخستین فرمان wg شکست بخورد، وقتی هسته میزبان آن ماژول را ندارد. و مرجع کانتینر Proxmox آن مدل هسته مشترک را همراه با مرزهای فضای نام و امتیازهایی که در آن کار می‌کنید مستند میکند.
قدرت، محدودیت دوم است. بالا آوردن یک رابط و اتصال نشانی‌ها به آن نیازمند حقوق مدیریت شبکه درون فضای نامی است که مالک آن است، و کانتینر بدون امتیاز این حقوق را از طریق فضای نام کاربری خود نگاشت میکند نه اینکه مستقیم نگه دارد. هرگز به‌عنوان نخستین پاسخ به سراغ امتیاز کامل نروید؛ ببینید واقعاً چه چیزی از کانتینر خواسته می‌شود و همان را بدهید.
هسته میزبان نیز وابستگی مشترک است. به‌روزرسانی هسته Proxmox پیاده‌سازی WireGuard را زیر همه کانتینرها یکجا تغییر می‌دهد، که راحت است تا زمانی که یک به‌روزرسانی و انتظارات یک کانتینر با هم نسازند.
میزبان، کانتینر، ماشین مجازی: هر مکان واقعاً چه چیزی را مالک است
مکان‌یابی روی میزبان، 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 |
ماشین مجازی حافظه بیشتری و سیستم دیگری برای وصله کردن می‌خواهد، و در عوض تونل هسته خود، جدول مسیریابی خود و مرز یک اسنپ‌شات را می‌گیرد. وقتی VPN همان چیزی است که پس از یک تغییر بد به آن بازمی‌گردید، آن اسنپ‌شات ارزش سربار را دارد.
سه شرطی که به‌جای شما انتخاب می‌کنند
اگر تونل به نسخه‌ای از هسته یا ویژگی‌ای از WireGuard نیاز دارد که میزبان Proxmox آن را عرضه نمی‌کند، همین‌جا بایستید و از ماشین مجازی استفاده کنید. نمی‌توانید هسته تازه‌تری در کانتینر نصب کنید، و نباید هسته هایپروایزر را برای راضی کردن یک مهمان عوض کنید.
اگر تونل دروازه سایت برای پیشوندهای واقعی LAN است، بپرسید چه کسی از پیش مالک مسیر بازگشت است. کانتینر می‌تواند ترافیک را مسیریابی کند، اما رابط‌هایش در پشته میزبان می‌نشینند، پس میزبان در نهایت بخشی از پیکربندی را حمل میکند، چه برنامه‌ریزی کرده باشید چه نه. مکان‌یابی روی میزبان در این باره صادق است؛ مکان‌یابی در کانتینر اغلب نیست.
سپس شعاع اثر یک خطا را بسنجید. راه‌اندازی مجدد کانتینر ارزان است، بازیابی اسنپ‌شات ماشین مجازی قابل پیش‌بینی است، و تعمیر شبکه میزبان ممکن است به دسترسی فیزیکی یا کنسول نیاز داشته باشد. انتخاب درست آن است که بدترین حالتش را واقعاً می‌توانید در همان ساعتی که رخ می‌دهد بازیابی کنید.
پرسش چهارم به‌ندرت تعیین‌کننده است اما گفتنش می‌ارزد: آیا چیز دیگری روی میزبان باید رابط تونل را ببیند؟ اگر بله، مکان‌یابی روی میزبان یا در کانتینر این دید را محلی نگه می‌دارد، در حالی که ماشین مجازی شما را مجبور میکند میان مهمان و میزبان مسیریابی کنید.
پیش از عبور دادن ترافیک از آن، مکان‌یابی را اثبات کنید
پس از نصب، تأیید کنید که کدام هسته واقعاً به رابط سرویس می‌دهد و آیا به کانتینر قدرت کافی برای نگه داشتن آن داده شده است:
$ 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 استفاده کنید و تأیید کنید که گام بعدی و رابط با طراحی می‌خوانند، و مسیر بازگشت در سمت دور وجود دارد.
استقرار را با مالکی مکتوب رها کنید: کدام هسته پیاده‌سازی را حمل میکند، کدام فضای نام رابط را نگه می‌دارد، و دروازه اجازه ارسال کدام پیشوندها را دارد. آن یک جمله بیش از هر مقایسه معیاری سه مکان، از رخدادها جلوگیری میکند.