גרמו לכלל ip לשרוד התחברות מחדש עם systemd-networkd

הוסיפו כלל מדיניות עם ip rule והוא עובד עד שהקישור נעלם, ואז הוא פשוט איננו. שום דבר לא נכשל בקול: מצב הליבה השתנה, ואף בעל תצורה לא ידע שהכלל אמור להתקיים. זה כל ההבדל בין כלל ששורד לכלל שלא. במארח עם systemd-networkd הפתרון הוא לתת לכלל בעלים במקום להריץ את הפקודה שוב אחרי כל התחברות מחדש.

כלל קיים רק אם למישהו יש בעלות עליו

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

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

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

קראו את הגרסה לפני שאתם סומכים על הגדרה

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

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

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

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

הצהירו על הכלל ועל הטבלה שאליה הוא מצביע

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

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

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

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

בחרו בעל אחד לממשק

שני מנהלים על מנהרה אחת יוצרים מאבק שנראה כמו תקלה בשניהם. ייבוא תצורת wg-quick קיימת ל-networkd הוא הגירה ולא תוספת, והרצה של שניהם משאירה את הממשק ואת כללי שלו תחת שני בעלים.

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

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

תרגלו את אירועי מחזור החיים

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

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

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