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.
• പാത മാറിയതിന് ശേഷവും ലക്ഷ്യസ്ഥാനത്തിന്റെ ഇൻബൗണ്ട് നിയമങ്ങൾ യഥാർത്ഥ ഉറവിടത്തെ അനുവദിക്കുന്നു.