عضو حذف‌شده 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

برای کنترلر خودمیزبان، نسخه پشتیبان سازگار از هویت و پیکربندی آن نگه دارید. بازیابی‌ای که به وضعیت قدیمی‌تر بازمی‌گردد می‌تواند مجوزی قدیمی را هم با خود برگرداند و فهرست اعضا دقیقاً مانند پیش از خارج کردن از رده به نظر می‌رسد.

خارج کردن از رده زمانی کامل می‌شود که هویت قدیمی به هیچ چیز دسترسی نداشته باشد و رکورد رفته باشد. این کارها را به همین ترتیب انجام دهید تا عضو دیگر بازنگردد.