WireGuard ב-LXC או ב-VM על Proxmox: היכן הוא אמור לרוץ?
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 עבור כתובת לקוח ואשרו שהקפיצה הבאה והממשק תואמים לתכנון, ושמסלול החזור קיים בצד המרוחק.
השאירו את הפריסה עם בעלים כתוב: איזה קרנל נושא את המימוש, איזה מרחב שמות מחזיק בממשק ואילו קידומות השער רשאי להעביר. המשפט הזה מונע יותר תקלות מכל השוואת ביצועים בין שלושת המיקומים.