ZeroTier מציג ONLINE אבל ACCESS_DENIED: היכן מתקנים את זה?

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

מה ONLINE מודד

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

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

מה ACCESS_DENIED מבקש מכם

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

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

טקסט המצב הוא ענף, לא פסק דין

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

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

zerotier-cli status
zerotier-cli listnetworks

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

חברות שייכת לזהות

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

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

אמתו אחרי השינוי

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

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

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

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