מאושרים ב-ZeroTier אבל בלי כתובת? שתי הגדרות נפרדות
אישור חבר והקצאת כתובת לו הן שתי הגדרות. קראו את המאגר, מצב ההקצאה והמצב המוחל של הלקוח לפני שממציאים IP.
ZeroTier מציג את החבר כ-OK, הרשת מחוברת, ועדיין אין כתובת לפינג. השילוב הזה מרגיש כמו באג ובדרך כלל מדובר בתצורה מפוצלת: אישור חבר הוא מתג אחד, והקצאת כתובת לו היא מתג אחר. רשת יכולה לקבל מכשיר ולעולם לא להקצות לו דבר, כי מאגר הכתובות או מצב ההקצאה מעולם לא הוגדרו.
קראו את שני הצדדים לפני שמשנים אחד מהם. התשובה נראית בשני מקומות, ורק אחד מהם נמצא בבקר.
אישור והקצאה הם מתגים שונים
אישור עונה אם צומת זה רשאי להשתתף ברשת. הקצאת כתובת עונה מה הרשת נותנת לו לאחר שהוא משתתף, והתשובה הזו מגיעה ממאגר כתובות בתוספת מצב הקצאה. אף אחת מההגדרות אינה מחייבת את האחרת. האחת היא הרשאה והאחרת היא הקצאה.
תצורת בקר נושאת בדרך כלל מסלול מנוהל, טווח כתובות והמצב שקובע אם משתמשים בהקצאה אוטומטית. העתקת מזהה רשת מסביבה אחרת מביאה את החברות ולא דבר מהתצורה הזו.
לכן מכשיר יכול להיראות תקין ברשימת החברים בעוד שעמודת הכתובת המוקצית שלו נשארת ריקה. הבקר קיבל אותו ואין לו מה לתת. שתי הקביעות נכונות בו-זמנית.
| Layer | What it decides | Where it is configured |
|---|---|---|
| Membership | Whether the node may join | Member authorization on the network |
| Pool | Which addresses exist to hand out | Network address range |
| Assignment mode | Whether they are handed out automatically | Network v4/v6 assignment settings |
קריאת המצב האפקטיבי של החבר
שאלו את הלקוח מה הוא באמת קיבל ולא מה הבקר התכוון. הרשימה הפשוטה מציגה עמודות מצב וכתובת, וצורת ה-JSON מציגה את תצורת הרשת שהלקוח החל, כולל כתובות ומסלולים מנוהלים.
zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'השוו את שתי הפלטים עבור אותו מזהה רשת, ולא עבור המתאמים הפיזיים שמופיעים ברשימה של מערכת ההפעלה עצמה. שורה שמדווחת OK עם קבוצת כתובות ריקה מאשרת את פער ההקצאה ולא תקלת קישוריות. קריאת השורה הלא נכונה היא החצי השני של הטעות הזו.
מצב ACCESS_DENIED מפנה חזרה לאישור, וזה תיקון אחר. אם הפקודה כלל אינה יכולה לקרוא את אסימון האימות המקומי, הבעיה היא הרשאות מקומיות ולא דחייה של הבקר, והתיקון הוא במחשב שאתם יושבים מולו.
כשהלקוח מתעלם ממה שהבקר שולח
ללקוח יש הגדרות משלו שקובעות אם התצורה המנוהלת מוחלת. פרופיל שמשבית כתובות מנוהלות, מסלולים מנוהלים או טיפול במסלול ברירת המחדל יזרוק את מה שהרשת שולחת, ורשימת החברים עדיין תיראה נכונה מצד הבקר.
הדגלים האלה משפיעים רק על הצומת המקומי. שינוי שלהם לא משנה מה מקבלים חברים אחרים, והוא לא מתקן מאגר שמעולם לא הוגדר.
אם כך לאבחון שני ענפים: או שלבקר אין כתובת לתת, או שהלקוח דחה את זו שניתנה לו. אלה מובילים לתיקונים שונים במחשבים שונים. פלט ה-JSON מבחין ביניהם, כי הכתובת או חסרה בתצורת הרשת או קיימת וחסרה במצב המוחל של הלקוח.
מה לתקן במקום להמציא כתובת
הקלדת כתובת סטטית שרירותית היא האפשרות השלישית המפתה והגרועה ביותר. כתובת אקראית יכולה להתנגש בצומת אחר, לשבת מחוץ למסלולים שהרשת מפיצה, או ליפול לטווח שכללי חומת האש מתייחסים אליו אחרת. היא גם מסתירה את המאגר החסר מכל מי שיסתכל ברשת לאחר מכן. תקנו במקום זאת את ההקצאה, ותנו לבקר וללקוח להסכים על התוצאה.
שאלו את המנהל מה הרשת אמורה לתת, ואז ודאו שהמאגר מכסה את הטווח המיועד ושמצב ההקצאה פעיל. הצטרפו מחדש אחרי השינוי במקום לצפות שהלקוח יגיע בעצמו מיד לתצורה חדשה.
ברגע שמופיעה כתובת, בדקו את מה שבאמת הייתם צריכים: עמית, שירות או תת-רשת מאחורי שער. הגעה ל-LAN מאחורי חבר דורשת ניתוב והעברה מעבר לחברות, וגישה כללית לאינטרנט דורשת צומת יציאה, כך שכתובת עובדת היא תחילת הבדיקה ולא סופה.