WireGuard: אין נתיב אל העמית לאחר שינוי תת־רשת — שתי דרכים החוצה
שינוי תת־רשת שובר את WireGuard בשני מקומות: AllowedIPs ונתיב החזרה. השוו מספור מחדש במקום לבנייה מחדש של הממשק.
לחיצת היד טרייה ב־wg show, נקודת הקצה נכונה, המפתחות מעולם לא השתנו — והפינג עדיין אומר שאין נתיב אל העמית. שינית את תת־הרשת של המנהרה לפני שעה. התסמין הזה הוא חתימה של אי־התאמת קידומת ולא של בעיית מפתחות: WireGuard השלים את לחיצת היד ואז השליך את הנתונים משום שכתובת מקור אינה תואמת עוד למה שהעמית המקבל יקבל. יש שתי דרכים הגיוניות ליישם שינוי תת־רשת, והן נכשלות במקומות שונים.
שתי דרכים ליישם את השינוי, ומה כל אחת עולה
אפשרות A היא מספור מחדש במקום: ערוך את כתובת הממשק, את טווחי העמיתים, את הנתיבים ואת כל עותק של התצורה, ואז טען מחדש. אפשרות B היא לבנות ממשק שני על הקידומת החדשה לצד הישן, להעביר את העמיתים, ולהסיר את הממשק הישן לאחר שהתעבורה באמת עברה.
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
המצב המיושם למחצה הוא מה שהופך את אפשרות A למסוכנת, כי הוא לא נראה שבור. הממשק עולה, לחיצת היד מצליחה, ורק נתיב הנתונים נכשל. אפשרות B דורשת יותר עבודה אבל משאירה נתיב עובד בחיים בזמן שאתה מוצא כל התייחסות.
מה חייב לזוז יחד בצד שלך
ארבעה דברים במארח המקומי מתארים את אותה תת־רשת, ושינוי של אחד הוא שינוי של כולם: כתובת הממשק, ה־AllowedIPs של כל עמית, הנתיב שהמערכת משתמשת בו ליעדים האלה, וכל מה שהמנהל מתקין בשמך. עם wg-quick, השניים האחרונים נוצרים מהתצורה בכל פעם שהממשק עולה, כך שעותק מיושן מתקין מחדש בשקט את הקידומת הישנה.
השוו בין מה שמוגדר לבין מה שחי במקום לסמוך על אחד מהם:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5חיפוש הנתיב הוא השלב שאנשים מדלגים עליו. הוא עונה מה הליבה באמת תעשה ליעד, כולל נתיב ספציפי יותר שהשאיר מנהל או סביבת הרצה של מכולות. אם הוא מדווח על ממשק שונה מהמנהרה, התצורה אינה הבעיה.
עבור ממשק פועל, החל את הקובץ שנערך בלי לפרק את המנהרה:
wg syncconf wg0 <(wg-quick strip wg0)זה מעדכן עמיתים וטווחים במקום. זה לא מעדכן את כתובת הממשק או את הנתיבים, כי אלה אינם הגדרות של WireGuard — לכן מספור מחדש עדיין דורש יצירה מחדש של הממשק או שינוי הכתובת עם ip, ואז בדיקה חוזרת של הניתוב.
מה חייב לזוז יחד בקצה המרוחק
כאן שינוי תת־רשת בדרך כלל מת. AllowedIPs אינו רק רמז לניתוב; הוא גם רשימת כתובות המקור שעמית רשאי להציג. כשאתה ממספר מחדש לקוחות ומשאיר את ה־AllowedIPs של השרת על הקידומת הישנה, השרת מקבל את לחיצת היד, מקבל את החבילות המוצפנות וזורק אותן כי המקור הפנימי אינו תואם לאף טווח שהוא מקשר לאותו עמית. לא נרשמת שגיאה, והלקוח רואה פסק זמן.
לכן עדכן את הצד המקבל בכוונה: רשומת העמית בשרת חייבת לפרט את קידומת הלקוח החדשה, נתיב החזרה של השרת עצמו חייב להצביע על המנהרה עבור אותה קידומת, וכל רשת במורד מאחורי השרת חייבת ללמוד את הנתיב החדש. מדיניות חומת אש שנקבה בטווח הישן זקוקה לאותה התייחסות, וכך גם כל דבר שעושה בחירה לפי מקור.
האבחון שמפריד בין שני הכשלים זול. לחיצת יד טרייה בלי נתונים משמעה שהמנהרה למעלה והמיעון הפנימי אינו מסכים. אין לחיצת יד כלל משמעה שאתה מסתכל על נגישות או מפתחות. אל תסובב מפתחות בגלל בעיית קידומת; זה מאפס את הדבר היחיד שעבד.
עותקים מיושנים ששורדים את העריכה שלך
עריכת קובץ אינה אותו דבר כמו שינוי המערכת הפועלת, והעותקים רבים יותר ממה שאנשים מצפים: היחידה או המנהל שבבעלותם הממשק, פרופיל שני באותו שם בספרייה אחרת, מכולה עם תצורתה אפויה בתמונת מערכת, ממשק נתב שמחזיק בגרסה שנערכה אצלו, ואפליקציית לקוח שמייבאת מחדש מנהרה שמורה בעת ההפעלה. כל אחד מהם יכול להחזיר את הקידומת הישנה אחרי שהשינוי שלך נראה מושלם.
גם שמות נוסעים. אם הנתיב המספרי עובד אבל שם המארח נכשל, רשומת DNS פנימית או תצורת שירות עדיין מצביעה על כתובת המנהרה הישנה. תקן את ההתייחסות במקום להרחיב כל טווח עמית, מה שהיה מכסה על הבעיה האמיתית ומגדיל באותו זמן את רשימת הבקרה של המקור.
השאר נתיב התאוששות אחד פתוח בזמן שאתה עובד: דרך שנייה להיכנס למארח, קונסולה סדרתית, או החזרה מתוזמנת של קובצי התצורה. שינוי מנהרה שנועל אותך מחוץ למכונה שאתה משנה הוא הדרך הנפוצה ביותר להפוך את המשימה הזו לערב.
הבחירה בין השתיים, ואימות המעבר
בחר ב־A כשכל עמית שלך, המספר קטן, והפסקה קצרה מקובלת. בחר ב־B כשהעמיתים הם ידיים מרוחקות שאינך שולט בהן, כשקישור בין אתרים חייב להישאר למעלה, או כשאתה לא יכול להבטיח שכל עותק יעודכן במעבר אחד. במקרה כזה הוסף את הקידומת החדשה לשני הממשקים, העבר עמיתים אחד אחד, עקוב אחר התעבורה בחדש, ורק אז הסר את הממשק הישן ואת הנתיבים שלו.
בכל אחת מהאפשרויות השינוי הושלם כאשר ארבע בדיקות עוברות: לחיצת היד טרייה, חיפוש הנתיב ליעד בקידומת החדשה מציין את המנהרה, מטען של כמה מאות בתים עובר בשני הכיוונים, ואותו דבר נכון אחרי הפעלה מחדש של המארח או של המנהל. ה מדריך wg(8) הוא ההתייחסות למה שמשמעות AllowedIPs בכל כיוון, וכדאי לקרוא אותו שוב לפני שמרחיבים טווח כדי להעלים תסמין.
- לחיצת יד טרייה ואין נתונים: הסתכל על ה־AllowedIPs אצל המקבל לפני שנוגעים במפתחות.
- חיפוש הנתיב מצביע על הממשק הלא נכון: מנהל או מכולה הם הבעלים של הנתיב, לא הקובץ שלך.
- כתובת מספרית תקינה ושם מארח שבור: התייחסות ישנה, לא לולאת ניתוב.
- השינוי שלם רק כאשר אחרי הפעלה מחדש עדיין משתמשים בקידומת החדשה.