Nebula static_host_map: જે સરનામું લાઇટહાઉસ આપી શકતું નથી

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

બે કામ સાથે બે સરનામાં

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

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

ઓળખ ત્યાં જાય છે જ્યાં ઓળખની અપેક્ષા હોય. પહોંચશક્તિ નકશામાં જાય છે.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

નકશા એન્ટ્રીની રચના

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

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

ખોટો પોર્ટ ભૂલને બદલે મૌન આપે છે, કારણ કે UDP પાસે નકારવા માટે હેન્ડશેક નથી. તેથી એન્ટ્રીનું બંધારણ Nebula static_host_map સંદર્ભ સામે તપાસવું યોગ્ય છે, યાદદાસ્ત સામે નહીં. સંદર્ભ એન્ડપોઇન્ટ યાદીઓ અને DNS તાજું કરવાના વર્તનને પણ આવરી લે છે.

ઓવરલે પહેલાં બૂટસ્ટ્રેપ કામ કરવું જોઈએ

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

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

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

પ્રથમ હેન્ડશેક પછી શું થાય છે

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

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

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

જ્યારે શોધ કામ કરે અને એક પીઅર નહીં

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

જે નકશા પર બાકીનું બધું પહેલેથી આધાર રાખે છે તેને સંપાદિત કરતા પહેલા જોડીને તપાસો. નકશાનો ફેરફાર દરેક હોસ્ટને ખલેલ પહોંચાડે છે, તેથી તે સૌથી છેલ્લે અડવાની વસ્તુ છે, પહેલી નહીં.

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