Nebula રિલે કન્ફિગર થયેલ છે પણ વપરાતો નથી: ચકાસવા માટેની ત્રણ સેટિંગ્સ

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

કન્ફિગ સંપાદિત કરતા પહેલાં ત્રણ ભૂમિકાઓનો નકશો બનાવો

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

મિશ્ર ફ્લીટમાં વર્ઝન લાઇન મહત્ત્વની છે. રિલે હેન્ડલિંગ, પંચિંગ વર્તન અને સ્વીકૃત કન્ફિગ કી રિલીઝ વચ્ચે સરખા નથી, તેથી એવું ન ધારો કે જૂનું બિલ્ડ એ વિભાગ સમજે છે જેના માટે તે લખાયું ન હતું. હોસ્ટને એક જ માઇનર શ્રેણી પર લાવો, પછી દરેક હોસ્ટ પર nebula -test -config /etc/nebula/config.yml ચલાવો અને કોડ લાગુ ન કરતા ટ્રાન્સપોર્ટને ડિબગ કરતા પહેલાં આઉટપુટની તુલના કરો.

રિલે હોસ્ટ પર ફોરવર્ડિંગ ભૂમિકા સક્ષમ કરો

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

relay:
  am_relay: true

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

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

રિલેની જાહેરાત લક્ષ્ય તરફથી કરો, ક્લાયન્ટ તરફથી નહીં

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

જોડાતા પીઅરને રિલે વાપરવા દો

શરૂ કરનાર પક્ષને પોતાની પરવાનગીની જરૂર છે. relay.use_relays ડિફોલ્ટ રૂપે ચાલુ છે, તેથી શોધવા જેવો કેસ સ્પષ્ટ false છે, જે ઘણી વાર રિલે સુવિધા અસ્તિત્વમાં આવે તે પહેલાં લખાયેલા ટેમ્પલેટમાંથી કોપી થયેલો હોય છે અથવા સીધા માર્ગો ફરજિયાત કરવાના અગાઉના પ્રયાસમાંથી રહી ગયેલો હોય છે:

relay:
  use_relays: true

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

NAT ટ્રાવર્સલ સેટિંગ્સ આ બધા સાથે ક્રિયાપ્રતિક્રિયા કરે છે. punchy.punch બે પીઅરને સીધો માર્ગ ખોલવામાં મદદ કરે છે, અને જ્યારે તે સફળ થાય ત્યારે નિરીક્ષણ કરવા જેવો કોઈ રિલે ટ્રાફિક હોતો નથી; તે સફળતા છે, ખૂટતો રિલે નહીં. જે જોડી અવારનવાર કામ કરે તેનો અર્થ સામાન્ય રીતે એ છે કે પંચિંગ ક્યારેક સફળ થાય છે, તેથી એક પ્રયાસ પરથી નિષ્કર્ષ ન કાઢતાં તે જોડીને ઘણી વાર ચકાસો.

જે જોડી નિષ્ફળ ગઈ તેની સાથે ચકાસો, પછી ફરી લોડ કરો

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload ફક્ત ત્યારે કામ કરે છે જ્યારે સ્થાનિક યુનિટ ExecReload વ્યાખ્યાયિત કરે, અને પ્રોજેક્ટ સાથે આવતું યુનિટ તેમ કરતું નથી, તેથી સ્ટોક ઇન્સ્ટોલ પર સફળ થતું પગલું systemctl kill -s HUP છે. ફરી લોડ કર્યા પછી પ્રોસેસે ખોલેલા કન્ફિગ માર્ગ માટે જર્નલ વાંચો, જેથી તમે જાણો કે નવી ફાઇલ વંચાઈ છે, તમે ધારેલી ફાઇલ નહીં.

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

પછી ખાતરી કરો કે દરેક વિધાન તેના જ ફાઇલમાં બેઠું છે:

• ફોરવર્ડિંગ હોસ્ટ પર am_relay: true, અને તે હોસ્ટ બંને બાજુથી UDP પર પહોંચવા યોગ્ય.
• લક્ષ્ય પર તે હોસ્ટના Nebula સરનામાનું નામ આપતું relays:.
• જોડાણ શરૂ કરતા પીઅર પર use_relays: true.
• માર્ગ બદલાયા પછી પણ લક્ષ્યના ઇનબાઉન્ડ નિયમો ખરા સ્રોતને મંજૂરી આપે છે.