در ZeroTier مجاز شدهاید اما نشانی ندارید؟ دو تنظیم جداگانه
تأیید یک عضو و دادن نشانی به آن دو تنظیم جداگانهاند. پیش از ساختن یک IP، استخر، حالت تخصیص و وضعیت اعمالشدهٔ کلاینت را بخوانید.
ZeroTier عضو را OK نشان میدهد، شبکه متصل است، و هنوز نشانی برای ping وجود ندارد. این ترکیب مثل یک باگ به نظر میرسد و معمولاً یک پیکربندی دو نیمه است: تأیید عضو یک کلید است و دادن نشانی به آن کلید دیگری. یک شبکه میتواند دستگاهی را بپذیرد و هرگز چیزی به آن تخصیص ندهد، چون استخر نشانیها یا حالت تخصیص هرگز تنظیم نشده است.
پیش از تغییر هر کدام، هر دو طرف را بخوانید. پاسخ در دو جا دیده میشود و تنها یکی از آنها روی کنترلر است.
مجوز و تخصیص دو کلید متفاوتاند
مجوز پاسخ میدهد که آیا این گره میتواند در شبکه مشارکت کند. تخصیص نشانی پاسخ میدهد که شبکه پس از مشارکت چه چیزی به آن میدهد، و این پاسخ از یک استخر نشانی بههمراه حالت تخصیص میآید. هیچکدام از دو تنظیم دیگری را ایجاب نمیکند. یکی اجازه است و دیگری تخصیص.
پیکربندی کنترلر معمولاً یک مسیر مدیریتشده، یک بازهٔ نشانی و حالتی را حمل میکند که تعیین میکند تخصیص خودکار استفاده میشود یا نه. کپی کردن شناسهٔ شبکه از محیطی دیگر، عضویت را میآورد و هیچچیز از آن پیکربندی را نمیآورد.
به همین دلیل دستگاه میتواند در فهرست اعضا سالم به نظر برسد در حالی که ستون نشانی تخصیصیافتهاش خالی میماند. کنترلر آن را پذیرفته و چیزی برای دادن ندارد. هر دو گزاره همزمان درستاند.
| 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 پشت یک عضو به مسیریابی و ارسال فراتر از عضویت نیاز دارد و دسترسی عمومی به اینترنت به گرهٔ خروج نیاز دارد، پس نشانی کارآمد آغاز آن آزمون است نه پایانش.