ZeroTier সদস্যকে OK দেখাচ্ছে, নেটওয়ার্কে যোগ দেওয়া হয়েছে, তবুও পিং করার মতো কোনো ঠিকানা নেই। এই সমন্বয়টি বাগের মতো লাগে এবং সাধারণত এটি বিভক্ত কনফিগারেশন: সদস্য অনুমোদন করা একটি সুইচ, আর তাকে ঠিকানা দেওয়া আরেকটি। একটি নেটওয়ার্ক ডিভাইস গ্রহণ করে তাকে কখনো কিছু নিয়োগ না করতে পারে, কারণ অ্যাড্রেস পুল বা অ্যাসাইনমেন্ট মোড কখনো সেট করা হয়নি।

যেকোনো একটি বদলানোর আগে দুই দিকই পড়ুন। উত্তর দুই জায়গায় দৃশ্যমান, এবং তার মধ্যে কেবল একটি কন্ট্রোলারে আছে।

অনুমোদন আর অ্যাসাইনমেন্ট আলাদা সুইচ

অনুমোদন বলে এই নোড নেটওয়ার্কে অংশ নিতে পারবে কি না। অ্যাড্রেস অ্যাসাইনমেন্ট বলে যোগ দেওয়ার পর নেটওয়ার্ক তাকে কী দেয়, এবং সেই উত্তর আসে অ্যাড্রেস পুল আর অ্যাসাইনমেন্ট মোড থেকে। কোনো সেটিংই অন্যটিকে বাধ্যতামূলক করে না। একটি অনুমতি, অন্যটি বণ্টন।

কন্ট্রোলার কনফিগারেশনে সাধারণত একটি ম্যানেজড রুট, একটি অ্যাড্রেস রেঞ্জ এবং অটো-অ্যাসাইনমেন্ট ব্যবহার হবে কি না তা নির্ধারণকারী মোড থাকে। অন্য পরিবেশ থেকে নেটওয়ার্ক আইডি কপি করলে সদস্যপদ আসে, কিন্তু ওই কনফিগারেশনের কিছুই আসে না।

এই কারণেই কোনো ডিভাইস সদস্য তালিকায় সুস্থ দেখাতে পারে, অথচ তার অ্যাসাইনড-অ্যাড্রেস কলাম খালি থাকে। কন্ট্রোলার তাকে গ্রহণ করেছে এবং দেওয়ার মতো কিছু নেই। দুটি বাক্যই একই সময়ে সত্য।

LayerWhat it decidesWhere it is configured
MembershipWhether the node may joinMember authorization on the network
PoolWhich addresses exist to hand outNetwork address range
Assignment modeWhether they are handed out automaticallyNetwork v4/v6 assignment settings

সদস্যের কার্যকর অবস্থা পড়া

কন্ট্রোলার কী চেয়েছিল তা নয়, ক্লায়েন্ট আসলে কী পেয়েছে তা জিজ্ঞেস করুন। সাধারণ তালিকা স্টেটাস ও অ্যাড্রেস কলাম দেখায়, আর JSON রূপ দেখায় ক্লায়েন্ট যে নেটওয়ার্ক কনফিগারেশন প্রয়োগ করেছে, ম্যানেজড অ্যাড্রেস ও রুটসহ।

zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'

একই নেটওয়ার্ক আইডির জন্য দুটি আউটপুট তুলনা করুন, অপারেটিং সিস্টেমের নিজের তালিকায় দেখা ফিজিক্যাল অ্যাডাপ্টারের জন্য নয়। যে সারি খালি অ্যাড্রেস সেট নিয়ে OK জানায়, তা কানেক্টিভিটি ত্রুটি নয় বরং অ্যাসাইনমেন্টের ফাঁক নিশ্চিত করে। ভুল সারি পড়া এই ভুলের অন্য অর্ধেক।

ACCESS_DENIED স্ট্যাটাস অনুমোদনের দিকেই ইঙ্গিত করে, আর সেটি ভিন্ন মেরামত। যদি কমান্ড স্থানীয় প্রমাণীকরণ টোকেন একেবারেই পড়তে না পারে, তবে সমস্যা কন্ট্রোলারের প্রত্যাখ্যান নয়, স্থানীয় অনুমতি, এবং সমাধান আপনি যে মেশিনে বসে আছেন সেখানেই।

ক্লায়েন্ট যখন কন্ট্রোলারের পাঠানো উপেক্ষা করে

ক্লায়েন্টের নিজস্ব সেটিং আছে যা ঠিক করে ম্যানেজড কনফিগারেশন প্রয়োগ হবে কি না। যে প্রোফাইল ম্যানেজড অ্যাড্রেস, ম্যানেজড রুট বা ডিফল্ট-রুট হ্যান্ডলিং বন্ধ করে, সে নেটওয়ার্ক যা পাঠায় তা ফেলে দেবে, আর কন্ট্রোলারের দিক থেকে সদস্য তালিকা তখনো ঠিক দেখাবে।

এই ফ্ল্যাগগুলো কেবল স্থানীয় নোডকে প্রভাবিত করে। এগুলো বদলালে অন্য সদস্যরা কী পায় তা বদলায় না, আর কখনো সংজ্ঞায়িত না হওয়া পুলও ঠিক হয় না।

তাই রোগনির্ণয়ের দুটি শাখা: হয় কন্ট্রোলারের দেওয়ার মতো কোনো ঠিকানা নেই, নয়তো ক্লায়েন্ট তাকে দেওয়া ঠিকানাটি প্রত্যাখ্যান করেছে। এগুলো আলাদা মেশিনে আলাদা মেরামতে নিয়ে যায়। JSON আউটপুট এদের আলাদা করে, কারণ ঠিকানাটি হয় নেটওয়ার্কের কনফিগারেশনে নেই, নয়তো আছে অথচ ক্লায়েন্টের প্রয়োগ করা অবস্থায় অনুপস্থিত।

ঠিকানা বানানোর বদলে কী ঠিক করবেন

ইচ্ছেমতো একটি স্ট্যাটিক ঠিকানা টাইপ করা লোভনীয় তৃতীয় অপশন এবং সবচেয়ে খারাপ। একটি এলোমেলো ঠিকানা অন্য নোডের সঙ্গে সংঘর্ষে যেতে পারে, নেটওয়ার্ক যে রুটগুলো প্রচার করে তার বাইরে পড়তে পারে, বা এমন রেঞ্জে পড়তে পারে যা ফায়ারওয়াল নিয়ম ভিন্নভাবে দেখে। এটি পরবর্তীতে নেটওয়ার্কের দিকে তাকানো সবার কাছ থেকে অনুপস্থিত পুলটিও লুকিয়ে রাখে। বরং অ্যাসাইনমেন্ট ঠিক করুন, এবং কন্ট্রোলার ও ক্লায়েন্টকে ফলাফল নিয়ে একমত হতে দিন।

প্রশাসককে জিজ্ঞেস করুন নেটওয়ার্ক কী দেবে, তারপর যাচাই করুন পুলটি অভীষ্ট রেঞ্জ কভার করে এবং অ্যাসাইনমেন্ট মোড চালু আছে। পরিবর্তনের পর আবার যোগ দিন, ক্লায়েন্ট নিজে থেকেই সঙ্গে সঙ্গে নতুন কনফিগারেশনে পৌঁছে যাবে বলে আশা করবেন না।

একবার ঠিকানা দেখা গেলে, আপনার আসলে যা দরকার ছিল তা পরীক্ষা করুন: একটি পিয়ার, একটি সেবা, বা গেটওয়ের পেছনের একটি সাবনেট। সদস্যের পেছনের LAN-এ পৌঁছাতে সদস্যপদের বাইরেও রাউটিং ও ফরওয়ার্ডিং লাগে, আর সাধারণ ইন্টারনেট অ্যাক্সেসের জন্য এক্সিট নোড লাগে, তাই কাজ করা ঠিকানা ওই পরীক্ষার শুরু, শেষ নয়।

সম্পর্কিত নিবন্ধ