ZeroTier میں مجاز لیکن پتہ نہیں؟ دو الگ ترتیبات
رکن کی منظوری اور اسے پتہ دینا دو الگ ترتیبات ہیں۔ IP ایجاد کرنے سے پہلے پول، تفویض کا موڈ اور کلائنٹ کی لاگو حالت پڑھیں۔
ZeroTier رکن کو OK دکھاتا ہے، نیٹ ورک جڑ چکا ہے، اور پھر بھی ping کرنے کے لیے کوئی پتہ نہیں۔ یہ امتزاج بگ جیسا لگتا ہے اور عام طور پر بٹی ہوئی ترتیب ہوتا ہے: رکن کی منظوری ایک سوئچ ہے، اور اسے پتہ دینا دوسرا۔ نیٹ ورک کسی ڈیوائس کو قبول کر سکتا ہے اور اسے کبھی کچھ تفویض نہیں کر سکتا، کیونکہ پتوں کا پول یا تفویض کا موڈ کبھی مقرر نہیں کیا گیا۔
کسی ایک کو بدلنے سے پہلے دونوں پہلو پڑھیں۔ جواب دو جگہوں پر نظر آتا ہے، اور ان میں سے صرف ایک کنٹرولر پر ہے۔
اجازت اور تفویض مختلف سوئچ ہیں
اجازت جواب دیتی ہے کہ کیا یہ نوڈ نیٹ ورک میں حصہ لے سکتا ہے۔ پتہ تفویض جواب دیتا ہے کہ حصہ لینے کے بعد نیٹ ورک اسے کیا دیتا ہے، اور یہ جواب پتوں کے پول اور تفویض کے موڈ سے آتا ہے۔ کوئی ترتیب دوسری کو لازم نہیں کرتی۔ ایک اجازت ہے اور دوسری تقسیم۔
کنٹرولر کی ترتیب میں عام طور پر ایک منظم راستہ، پتوں کی حد اور وہ موڈ ہوتا ہے جو طے کرتا ہے کہ خودکار تفویض استعمال ہوتی ہے یا نہیں۔ کسی دوسرے ماحول سے نیٹ ورک ID کاپی کرنے سے رکنیت آتی ہے اور اس ترتیب سے کچھ نہیں آتا۔
اسی لیے ڈیوائس ارکان کی فہرست میں صحت مند دکھ سکتی ہے جبکہ اس کا تفویض شدہ پتہ کالم خالی رہتا ہے۔ کنٹرولر نے اسے قبول کر لیا ہے اور دینے کے لیے کچھ نہیں ہے۔ دونوں باتیں بیک وقت درست ہیں۔
| 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}'دونوں آؤٹ پٹ کا موازنہ ایک ہی نیٹ ورک ID کے لیے کریں، نہ کہ آپریٹنگ سسٹم کی اپنی فہرست میں نظر آنے والے جسمانی اڈاپٹروں کے لیے۔ خالی پتہ مجموعہ کے ساتھ OK بتانے والی سطر کنیکٹیویٹی خرابی نہیں بلکہ تفویض کے خلا کی تصدیق کرتی ہے۔ غلط سطر پڑھنا اس غلطی کا دوسرا نصف ہے۔
ACCESS_DENIED حالت اجازت کی طرف اشارہ کرتی ہے، اور وہ الگ مرمت ہے۔ اگر کمانڈ مقامی توثیقی ٹوکن بالکل نہ پڑھ سکے، تو مسئلہ کنٹرولر کا انکار نہیں بلکہ مقامی اجازتیں ہیں، اور اصلاح اسی مشین پر ہے جہاں آپ بیٹھے ہیں۔
جب کلائنٹ کنٹرولر کی بھیجی ہوئی چیز کو نظر انداز کرتا ہے
کلائنٹ کی اپنی ترتیبات ہیں جو طے کرتی ہیں کہ منظم ترتیب لاگو ہوتی ہے یا نہیں۔ جو پروفائل منظم پتے، منظم راستے یا ڈیفالٹ راستے کی دیکھ بھال بند کرتا ہے وہ نیٹ ورک کی بھیجی ہوئی چیز پھینک دیتا ہے، اور ارکان کی فہرست کنٹرولر کی طرف سے پھر بھی درست دکھائی دے گی۔
یہ جھنڈے صرف مقامی نوڈ پر اثر ڈالتے ہیں۔ انہیں بدلنے سے دوسرے ارکان کو کیا ملتا ہے وہ نہیں بدلتا، اور کبھی متعین نہ ہوا پول بھی درست نہیں ہوتا۔
چنانچہ تشخیص کی دو شاخیں ہیں: یا کنٹرولر کے پاس دینے کو پتہ نہیں، یا کلائنٹ نے دیا گیا پتہ رد کر دیا۔ یہ مختلف مشینوں پر مختلف مرمتوں کی طرف لے جاتے ہیں۔ JSON آؤٹ پٹ انہیں الگ کرتا ہے، کیونکہ پتہ یا نیٹ ورک کی ترتیب میں نہیں ہے، یا ہے اور کلائنٹ کی لاگو حالت میں نہیں۔
پتہ ایجاد کرنے کے بجائے کیا درست کریں
من مانی مستقل پتہ ٹائپ کرنا دلکش تیسرا آپشن اور بدترین ہے۔ بے ترتیب پتہ کسی دوسرے نوڈ سے ٹکرا سکتا ہے، ان راستوں سے باہر ہو سکتا ہے جو نیٹ ورک پھیلاتا ہے، یا ایسی حد میں پڑ سکتا ہے جسے فائر وال قواعد مختلف طریقے سے لیتے ہیں۔ یہ آگے نیٹ ورک دیکھنے والے ہر شخص سے غائب پول بھی چھپا دیتا ہے۔ اس کے بجائے تفویض درست کریں، اور کنٹرولر اور کلائنٹ کو نتیجے پر متفق ہونے دیں۔
منتظم سے پوچھیں کہ نیٹ ورک کو کیا دینا چاہیے، پھر جانچیں کہ پول مطلوبہ حد کو ڈھکتا ہے اور تفویض کا موڈ فعال ہے۔ تبدیلی کے بعد دوبارہ جڑیں، بجائے اس کے کہ کلائنٹ خود فوراً نئی ترتیب تک پہنچ جائے گا۔
پتہ ظاہر ہونے پر وہ چیز آزمائیں جو واقعی درکار تھی: کوئی پیر، کوئی سروس یا گیٹ وے کے پیچھے کوئی ذیلی نیٹ ورک۔ رکن کے پیچھے LAN تک پہنچنے کے لیے رکنیت سے آگے روٹنگ اور فارورڈنگ چاہیے، اور عام انٹرنیٹ رسائی کے لیے ایگزٹ نوڈ چاہیے، اس لیے کام کرنے والا پتہ اس آزمائش کا آغاز ہے، اختتام نہیں۔