Nebula: הממסר מוגדר אך אינו בשימוש — שלוש הגדרות לבדיקה

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

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

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

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

הפעילו את תפקיד ההעברה במארח הממסר

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

relay:
  am_relay: true

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

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

פרסמו את הממסר מהיעד, לא מהלקוח

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

אפשרו לעמית המתחבר להשתמש בממסר

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

relay:
  use_relays: true

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

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

אמתו עם הזוג שנכשל, ואז טענו מחדש

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload עובד רק כשהיחידה המקומית מגדירה ExecReload, והיחידה שמגיעה עם הפרויקט לא עושה זאת, ולכן systemctl kill -s HUP הוא הצעד שמצליח בהתקנה סטנדרטית. לאחר הטעינה מחדש קראו את היומן עבור נתיב התצורה שהתהליך פתח, כדי שתדעו שהקובץ החדש נקרא ולא זה שהנחתם.

הגדרות ממסר וניקוב NAT פועלות שתיהן על הנתיב; אף אחת מהן לא פועלת על הזהות. אם הזוג עדיין נכשל בלחיצת היד לאחר ש-am_relay, relays ו-use_relays אושרו בתצורה הרצה, בדקו ששני המארחים מציגים תעודות שהונפקו עבור השמות שהם מוגדרים איתם ושה-CA זהה בשני הצדדים. החזיקו את התעודה ואת תצורת חומת האש קבועות בזמן שאתם משנים הגדרת תחבורה אחת בכל פעם, מפני שעריכת תעודה ועריכת ממסר שנופלות באותה בדיקה לא אומרות לכם מה הזיז את לחיצת היד. אי-התאמה בשם או ב-CA נכשלת באותו מקום כמו ממסר שמעולם לא נמצא, ולכן הבדיקה שכנגד שייכת לאותו מעבר.

ואז ודאו שכל הצהרה יושבת בקובץ שאליו היא שייכת:

• am_relay: true במארח ההעברה, ושהמארח הזה נגיש ב-UDP משני הצדדים.
• relays: שמציין את כתובת ה-Nebula של אותו מארח ביעד.
• use_relays: true בעמית שמתחיל את החיבור.
• כללי כניסה ביעד עדיין מאפשרים את המקור האמיתי לאחר שהנתיב משתנה.