Nebula static_host_map: הכתובת שמגדלור לא יכול לתת

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

שתי כתובות עם שני תפקידים

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

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

זהות הולכת לאן שמצפים לזהות. נגישות הולכת למפה.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

אנטומיה של רשומה במפה

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

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

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

האתחול חייב לעבוד לפני ה-overlay

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

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

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

מה קורה אחרי לחיצת היד הראשונה

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

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

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

כשהגילוי עובד ועמית אחד לא

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

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

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