ZeroTier ONLINE દર્શાવે છે પણ ACCESS_DENIED: આ ક્યાં સુધારવું?

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

ONLINE શું માપે છે

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

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

ACCESS_DENIED તમારી પાસે શું માંગે છે

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

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

સ્ટેટસ લખાણ એ શાખા છે, ચુકાદો નહીં

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

બે આદેશ આ બધું અલગ પાડે છે, અને બંને એક જ ક્લાયન્ટ વાંચે છે. ZeroTier CLI સંદર્ભ દરેક નેટવર્ક માટેના સ્ટેટસ સ્ટ્રિંગની યાદી આપે છે જે તેઓ પરત કરે છે. પ્રથમ આદેશ સેવાનું દૃશ્ય છે અને બીજો દરેક નેટવર્ક માટે છે:

zerotier-cli status
zerotier-cli listnetworks

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

સભ્યપદ ઓળખનું છે

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

ઉપકરણ નિવૃત્ત કરો ત્યારે પહેલાં તેની અધિકૃતિ પાછી ખેંચો અને કંઈપણ દૂર કરતા પહેલાં ખાતરી કરો કે એન્ટ્રી એ સ્થિતિ દર્શાવે છે. ક્રમ એ સ્વચ્છ દૂર કરવા અને રહસ્યમય પુનઃજોડાણ વચ્ચેનો ફરક છે.

ફેરફાર પછી ચકાસો

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

zerotier-cli listnetworks
ip -br addr show
ping -c 2 10.147.20.5
ip route get 10.147.20.5

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

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