ZeroTier સભ્યને OK તરીકે દર્શાવે છે, નેટવર્ક જોડાયેલું છે, અને તેમ છતાં પિંગ કરવા માટે કોઈ સરનામું નથી. આ સંયોજન ભૂલ જેવું લાગે છે અને સામાન્ય રીતે તે વિભાજિત રૂપરેખાંકન છે: સભ્યને મંજૂર કરવો એ એક સ્વિચ છે, અને તેને સરનામું આપવું એ બીજું છે. નેટવર્ક ઉપકરણ સ્વીકારી શકે છે અને તેને ક્યારેય કંઈ સોંપી શકતું નથી, કારણ કે સરનામા પૂલ અથવા સોંપણી મોડ ક્યારેય સેટ કરવામાં આવ્યો નહોતો.

બંનેમાંથી કોઈપણ બદલતા પહેલાં બંને બાજુ વાંચો. જવાબ બે જગ્યાએ દેખાય છે, અને તેમાંથી ફક્ત એક જ કંટ્રોલર પર છે.

અધિકૃતિ અને સોંપણી અલગ સ્વિચ છે

અધિકૃતિ જવાબ આપે છે કે આ નોડ નેટવર્કમાં ભાગ લઈ શકે છે કે નહીં. સરનામા સોંપણી જવાબ આપે છે કે ભાગ લીધા પછી નેટવર્ક તેને શું આપે છે, અને તે જવાબ સરનામા પૂલ અને સોંપણી મોડમાંથી આવે છે. બંનેમાંથી કોઈ પણ સેટિંગ બીજાને સૂચવતું નથી. એક પરવાનગી છે અને બીજું ફાળવણી છે.

કંટ્રોલર રૂપરેખાંકનમાં સામાન્ય રીતે મેનેજ્ડ રૂટ, સરનામા શ્રેણી અને સ્વયં-સોંપણી વપરાય છે કે નહીં તે નક્કી કરતો મોડ હોય છે. બીજા વાતાવરણમાંથી નેટવર્ક ID કોપી કરવાથી સભ્યપદ આવે છે અને તે રૂપરેખાંકનમાંથી કંઈ આવતું નથી.

તેથી ઉપકરણ સભ્ય યાદીમાં સ્વસ્થ દેખાઈ શકે છે જ્યારે તેનો સોંપાયેલ સરનામાનો કૉલમ ખાલી રહે છે. કંટ્રોલરે તેને સ્વીકાર્યું છે અને તેની પાસે આપવા માટે કંઈ નથી. બંને વિધાનો એક જ સમયે સાચા છે.

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}'

બે આઉટપુટની સરખામણી એક જ નેટવર્ક ID માટે કરો, ઓપરેટિંગ સિસ્ટમની પોતાની યાદીમાં દેખાતા ભૌતિક એડેપ્ટર માટે નહીં. ખાલી સરનામા સમૂહ સાથે OK જણાવતી પંક્તિ સોંપણીની ખાલી જગ્યા પુષ્ટિ કરે છે, કનેક્ટિવિટી ખામી નહીં. ખોટી પંક્તિ વાંચવી એ આ ભૂલનો બીજો અડધો ભાગ છે.

ACCESS_DENIED સ્થિતિ અધિકૃતિ તરફ પાછી નિર્દેશ કરે છે, અને તે અલગ સમારકામ છે. જો આદેશ સ્થાનિક પ્રમાણીકરણ ટોકન વાંચી જ શકતો ન હોય, તો સમસ્યા સ્થાનિક પરવાનગીઓની છે, કંટ્રોલરની અસ્વીકૃતિની નહીં, અને સુધારો તમે જે મશીન પર બેઠા છો ત્યાં જ છે.

જ્યારે ક્લાયન્ટ કંટ્રોલર મોકલે છે તેની અવગણના કરે છે

ક્લાયન્ટની પોતાની સેટિંગ છે જે નક્કી કરે છે કે મેનેજ્ડ રૂપરેખાંકન લાગુ થાય છે કે નહીં. જે પ્રોફાઇલ મેનેજ્ડ સરનામાં, મેનેજ્ડ રૂટ અથવા ડિફોલ્ટ રૂટની સંભાળ બંધ કરે છે તે નેટવર્ક મોકલે છે તે ફેંકી દેશે, અને સભ્ય યાદી કંટ્રોલરની બાજુથી હજી પણ સાચી દેખાશે.

આ ફ્લેગ ફક્ત સ્થાનિક નોડને અસર કરે છે. તેને બદલવાથી અન્ય સભ્યોને શું મળે છે તે બદલાતું નથી, અને ક્યારેય વ્યાખ્યાયિત ન થયેલા પૂલને સુધારતું નથી.

તેથી નિદાનની બે શાખાઓ છે: કાં તો કંટ્રોલર પાસે આપવા માટે સરનામું નથી, અથવા ક્લાયન્ટે આપવામાં આવેલું સરનામું નકાર્યું છે. તે અલગ મશીનો પર અલગ સમારકામ તરફ દોરી જાય છે. JSON આઉટપુટ તેમને અલગ પાડે છે, કારણ કે સરનામું કાં તો નેટવર્કના રૂપરેખાંકનમાં નથી, અથવા છે અને ક્લાયન્ટની લાગુ કરેલી સ્થિતિમાં ખૂટે છે.

સરનામું શોધવાને બદલે શું સુધારવું

મનસ્વી સ્થિર સરનામું ટાઇપ કરવું એ લલચાવતો ત્રીજો વિકલ્પ અને સૌથી ખરાબ છે. રેન્ડમ સરનામું બીજા નોડ સાથે અથડાઈ શકે છે, નેટવર્ક ફેલાવે છે તે રૂટની બહાર રહી શકે છે, અથવા એવી શ્રેણીમાં પડી શકે છે જેને ફાયરવોલ નિયમો અલગ રીતે લે છે. તે આગળ જે નેટવર્ક તરફ જોશે તેનાથી ખૂટતો પૂલ પણ છુપાવે છે. તેના બદલે સોંપણી સુધારો, અને કંટ્રોલર અને ક્લાયન્ટને પરિણામ પર સહમત થવા દો.

વ્યવસ્થાપકને પૂછો કે નેટવર્ક શું આપવાનું છે, પછી ચકાસો કે પૂલ ઇચ્છિત શ્રેણીને આવરી લે છે અને સોંપણી મોડ સક્ષમ છે. ફેરફાર પછી ફરી જોડાઓ, ક્લાયન્ટ પોતે જ તરત નવા રૂપરેખાંકન સુધી પહોંચી જશે એવી અપેક્ષા રાખવાને બદલે.

એકવાર સરનામું દેખાય, તો તમને ખરેખર શું જોઈએ હતું તે ચકાસો: પીઅર, સેવા, અથવા ગેટવે પાછળનું સબનેટ. સભ્ય પાછળના LAN સુધી પહોંચવા માટે સભ્યપદની બહાર રૂટિંગ અને ફોરવર્ડિંગ જોઈએ, અને સામાન્ય ઇન્ટરનેટ ઍક્સેસ માટે એક્ઝિટ નોડ જોઈએ, તેથી કાર્યક્ષમ સરનામું તે કસોટીની શરૂઆત છે, અંત નહીં.

સંબંધિત લેખો