חבר ZeroTier שנמחק חוזר: בטלו קודם את ההרשאה
התקן שמחובר לרשת יכול לבקש שוב להצטרף ברגע שהרשומה שלו מוסרת. בטלו את ההרשאה, ואחר כך התייחסו למחיקה כאל ניקוי של הרשימה.
אתם מוחקים את החבר, סוגרים את הדף, ולמחרת אותו התקן חזר. זו אינה תקלה בקונסולה. זה מה שקורה כשמוחקים רשומה בזמן שהתקן עדיין מחובר ועדיין מבקש להצטרף.
שתי פעולות יושבות זו לצד זו ועושות עבודות שונות. האחת מכריעה בנוגע לגישה, והאחרת רק מסדרת את הרשימה.
התחילו מהרשומה שחוזרת
פתחו את הרשת והסתכלו על הרשומה שחזרה. רשמו את ה-node ID שלה, את הכתובת האחרונה שלה ואת השעה שבה הופיעה שוב. השוו אותה להתקן שרציתם להוציא משימוש. שם התצוגה הוא מה שמישהו הקליד, והכתובת יכולה להשתנות בהצטרפות הבאה.
ה-node ID הוא המזהה היציב. מזהה רשת נותן שם לרשת, כך שהוא אומר לכם איזו רשימה אתם קוראים ושום דבר על איזה התקן נמצא בה. רשמו את שניהם, ואחר כך התאימו את ה-node ID למכונה שרציתם להוציא משימוש.
אם תטעו בהשוואה הזו, תסירו מכונה שעובדת בזמן שהמכונה הלא רצויה ממשיכה לבקש. אז הרשימה נראית נכונה למשך יום. זה מספיק זמן כדי שאיש לא ישים לב, וזו בדיוק הבעיה.
בטלו לפני שמוחקים
שנו קודם את מצב ההרשאה דרך זרימת העבודה שהבקר תומך בה. מאותו רגע, ניסיון הצטרפות מופיע כלא מורשה במקום לשחזר גישה בשקט, והבקשה גלויה ולא בלתי נראית.
המחיקה באה אחר כך, ולעולם לא במקומה. הסרת הרשומה של חבר מורשה אינה משאירה דבר לבטל. ההתקן שואל שוב, והבקר מתייחס אליו כאל חדש.
עבור מכונה שאתם עדיין שולטים בה, יציאה מהרשת היא חלק שימושי מהוצאת משימוש. היא אינה מחליפה את החלטת המנהל לגבי התקן שאבד. לקוח שאינכם שולטים בו עוד יכול להתעלם מכל מה שנאמר לו.
היכן שתי הפעולות נמצאות
בבקר מתארח, רשימת החברים מציעה את שתי הפעולות ומתייגת אותן בבהירות מספקת כדי להבחין ביניהן. בבקר מתארח בעצמכם, אותו הבדל מופיע ב-API ובתצורה המקומית, ומשם בדרך כלל מתחילה הבלבול.
# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
"http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'
# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
"http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"
שני הקריאות האלה מספיקות כדי להראות אם החבר היה אי פעם באמת ללא הרשאה. רשומה שחוזרת שוב ושוב עם authorized: true מעולם לא בוטלה; היא רק נמחקה.
אמתו מהמשאב, לא מהרשימה
רשימת חברים מסודרת אינה בדיקת גישה. נסו את המשאב שההתקן השתמש בו קודם, מההתקן הזה או ממכונה שמחזיקה את הכתובת הישנה שלו, ואמתו שהחיבור נכשל. אחר כך אמתו שמחליף מאושר עדיין עובד.
כללו מסלולים והרשאות שירות בבדיקה הזו. ZeroTier יכול להרשות לחבר ולהשאיר אותו בכל זאת בלי יכולת להגיע למסלול מנוהל. הרשאת יישום יכולה להיכשל באותה דרך. שניהם נראים זהים מרשימת החברים.
zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5
בבקר מתארח בעצמכם, החזיקו גיבוי עקבי של הזהות והתצורה שלו. שחזור שמגלגל אחורה למצב קודם יכול להחזיר איתו הרשאה ישנה, ורשימת החברים תיראה בדיוק כפי שנראתה לפני ההוצאה משימוש.
ההוצאה משימוש מסתיימת כשהזהות הישנה אינה יכולה להגיע לשום דבר והרשומה נעלמה. עשו זאת בסדר הזה והחבר יפסיק לחזור.