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

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

מה טעינה מחדש קוראת באמת מחדש

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

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

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

כתובת, שם וקבוצות הם זהות אחת

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

FieldWhat changes when you replace it
Overlay addressPeers that pinned the old address, service bindings, and any rule written against it
Host nameName-based policy and the identities other hosts expect to see
GroupsWhich access rules match, even if the address stays identical
Validity windowNothing structural, which is why renewal reloads cleanly

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

השוו את התעודה הטעונה להחלפה

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

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

הארגומנטים של התהליך חשובים יותר ממה שאנשים מצפים. יחידה שמעבירה את -config /etc/nebula/config.yml קוראת את רשומת ה-pki.cert של אותו קובץ, ותעודה שמותקנת בספרייה זמנית לא משפיעה על דבר. בדקו את הנתיב בשורת הפקודה הרצה, לא את הנתיב בתיעוד שלפיו פעלתם. אם השניים שונים, מצאתם את הבעיה בלי לגעת בתעודה כלל.

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

שינוי כתובת הוא שינוי ברשת

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

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

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

הסירו את אישור הכניסה הישן בנפרד

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

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

מאמרים קשורים