למה peer של WireGuard שנמחק חוזר אחרי הפעלה מחדש

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

שני מצבים מחזיקים את הרשימה הזו. ביטול הוא אמיתי רק כששניהם מאבדים אותה.

מה wg set באמת משנה

הפקודה wg set wg0 peer <public-key> remove עורכת את הממשק הרץ בתוך הקרנל. היא לא כותבת דבר לדיסק. קובץ התצורה, פרופיל ה-NetworkManager או המצב השמור של הנתב נשארים ללא שינוי. זהו התכנון, לא תקלה.

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

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

מצאו את הכותב לפני שאתם עורכים קובץ

לממשק יש בעלים. זה יכול להיות wg-quick שקורא קובץ, NetworkManager שמחיל פרופיל, תצורת הממשק של הנתב עצמו, או נקודת כניסה של מכולה שיוצרת את הממשק מחדש בעת האתחול. עריכת קובץ שהבעלים אף פעם לא קורא לא מייצרת שום שינוי מתמשך.

התחילו מהממשק הרץ וזהו את המפתחות הציבוריים, כי שמות וכתובות הם מזהים חלשים יותר מהמפתח עצמו. אחר כך השוו את הרשימה הזו לתצורה השמורה שהבעלים באמת קורא.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

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

מלכודת SaveConfig

wg-quick מוסיף קפל שתופס אנשים שעורכים קבצים ביד. כש-SaveConfig מופעל, התנהגות הכיבוי המתועדת שלו כותבת את מצב זמן הריצה הנוכחי על גבי קובץ התצורה.

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

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

שנו את שני המצבים ואז טענו מחדש

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

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

השאירו נתיב התאוששות פתוח אם השער נושא גם את הגישה הניהולית שלכם. הפעלה מחדש שמסירה את ה-peer הלא נכון היא השבתה שגרמתם לעצמכם. אותו דבר חל על הפעלה מחדש שמסירה את המסלול הלא נכון.

איך נראית בדיקה שעוברת

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

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

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

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