אתחול ראשון: רישום עבור צי של התקני WireGuard

הלוח עולה מהתמונה המשותפת, מקבל חכירת DHCP, וסקריפט אספקה רץ לפני שמישהו נגע בהתקן. במקום כלשהו בסקריפט הזה עליו להשיג זהות WireGuard ששייכת ללוח הזה ולא לאחר, להביא לאישור של הזהות הזו, ולכתוב פרופיל שהשער יקבל. התמונה יכולה לשאת את תוכנת הלקוח, תבנית שנבדקה ואת המפתח הציבורי של השער. מה שאסור לה לשאת לעולם הוא מפתח פרטי אחד שמשותף לכל הצי, מפני שזה הופך לוח גנוב אחד לתקרית של כל הצי. הסדר שלהלן שומר על הזהות מקומית ועל ההרשאה מפורשת.

מה התמונה נושאת, ומה לא

שלחו את החבילה, את התבנית עם מחזיקי מקום, את המפתח הציבורי של השער ואת לקוח הרישום. התבנית היא צורה, לא סוד: היא צריכה להיות קריאה למשתמש האספקה ולא להכיל שום חומר מפתח.

המפתח הפרטי נוצר בהתקן באתחול הראשון ולעולם אינו עוזב אותו. רק החצי הציבורי נוסע, בתוך בקשת רישום שמאושרת על ידי משהו אחר מאשר ההצהרה של ההתקן עצמו על מי הוא. ההבחנה הזו היא שמונעת מלוח גנוב להפוך לבעיה של כל הצי. והיא גם החלק שרוב סקריפטי האתחול הראשוני עושים לא נכון.

שלב 1: ליצור את המפתח באופן מקומי

הריצו את היצירה בספרייה מוגנת לאחר שחיבור הרשת הבסיסי אושר ועובד. תת-המעטפת משאירה את שינוי ה-umask מקומי לפעולה הזו, ו-set -C מסרב לדרוס קובץ קיים:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

התחלה מהירה של WireGuard מתעד את יחסי יצירת המפתחות שעליהם נשענות שתי הפקודות האלה. אם היצירה נקטעת, השאירו את ההתקן ללא רישום ותנו לזרימת העבודה ליישב את הקבצים. אל תמחקו זהות קיימת רק כדי שהסקריפט ירוץ נקי מההתחלה.

שמרו על המפתח הממתין בין ניסיונות חוזרים. יצירה מחדש של זהות אחרי כל כשל רשת זמני היא הדרך שבה צי נשאר עם peers יתומים שאיש אינו יכול להתאים להתקן.

שלב 2: לאשר רשומת התקן

נניח שהמלאי קורא ללוח הזה device-042 ומקצה לו 10.90.0.42/32. שירות הרישום חייב לוודא שהמבקש הזה זכאי לרשומה הזו. מספר סידורי שהוקלד בטופס אינו הוכחה, מפני שמספרים סידוריים מודפסים על הצד החיצוני של הקופסה.

אישור אתחול לכל התקן, אישור של מפעיל או אטסטציה נתמכת חומרה יכולים לבסס את ההצהרה. הגנו על שלמות הבקשה ועל מהימנות התגובה, ואל תחליפו סוד VPN משותף אחד באישור מפעל משותף אחד.

הרשומה הנרשמת קושרת את ההתקן, את המפתח הציבורי שלו, את הכתובת שהוקצתה לו ואת תפקיד הניהול המותר שלו. WireGuard עצמו אינו מגדיר API רישום, ולכן השירות הזה הוא משהו שאתם בונים ומפעילים בכוונה.

שלב 3: לכתוב שתי תצורות תואמות

ההתקן זקוק לפרופיל שמנתב את קידומות הניהול לתוך המנהרה, והשער זקוק לרשומת peer שמתירה רק את כתובת המקור של ההתקן הזה עצמו. עם שער בכתובת 10.90.0.1 ורשת ניהול של 10.60.0.0/16, צד ההתקן נראה כך:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

הערכים שבסוגריים הם מחזיקי מקום, לא מפתחות. ה-keepalive חשוב כשהלוח יושב מאחורי NAT וחייב להישאר נגיש; הוא אינו נדרש בכל מקום, והוספה שלו מתוך הרגל משאירה רדיו ער בלי סיבה.

בשער, רשומת ה-peer צרה בכוונה:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

אל תעתיקו את רשימת היעדים של ההתקן ל-peer של השער. בהתקן הרשימה הזו אומרת מה לנתב לתוך המנהרה; בשער היא אומרת אילו כתובות מקור ה-peer הזה רשאי להשתמש בהן, ואלה הצהרות שונות.

העברה, כללי חומת אש ונתיב החזרה לרשת הניהול עדיין חייבים להתיר את הגישה המאושרת. peer רשום אינו הרשאה לכל יישום שמאחוריו.

שלב 4: לקבע את הרישום כמצב מחזור חיים

החילו את רשומת השער ואת פרופיל ההתקן דרך מי שמחזיק בכל תצורה, ואז סמנו את הרישום כמושלם רק כשהזהות והכתובת המיועדות מתקבלות. ניסיונות חוזרים צריכים ליישב את אותה רשומה במקום להקצות peer שני או כתובת שנייה.

שמרו נתיב התאוששות לאספקה שנקטעה, כולל המקרה שבו השער קיבל את המפתח וההתקן מעולם לא כתב את הפרופיל שלו.

כשלוח מוחלף או מוצא משירות, הסירו את המפתח הציבורי שלו ואת ההרשאה שלו יחד. מפתח חדש הוא אירוע רישום מחדש מכוון, לא תופעת לוואי של יצירת תמונה מחדש. סדר העבודה: ליצור מקומית, לאשר מול המלאי, לכתוב את שני הצדדים, לקבע את המצב, ואז לבדוק בקשת ניהול אחת דרך המנהרה.