Nebula static_host_map: ലൈറ്റ്ഹൗസിന് നൽകാനാവാത്ത വിലാസം

ഓരോ ലൈറ്റ്ഹൗസിനും ഏതൊരു ഹോസ്റ്റിനോടും മറ്റെല്ലാ പിയറുകളെക്കുറിച്ച് പറയാം, ലൈറ്റ്ഹൗസ് തന്നെ എവിടെയാണെന്നത് ഒഴികെ. overlay നിലവിൽ വരുന്നതിന് മുമ്പ് എന്തെങ്കിലും അറിയപ്പെട്ടിരിക്കണം, Nebula ആ എന്തോ ഒരു ചെറിയ മാപ്പിൽ ഇടുന്നു. മാപ്പ് overlay ഐഡന്റിറ്റിയെ സാധാരണ നെറ്റ്വർക്കിൽ പ്രവർത്തിക്കുന്ന ഒരു വിലാസവുമായി ജോടിയാക്കുന്നു. പിന്നീട് പഠിക്കുന്നതെല്ലാം ആ ജോടി ശരിയായിരിക്കുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

രണ്ട് ജോലികളുള്ള രണ്ട് വിലാസങ്ങൾ

ഓരോ Nebula ഹോസ്റ്റിനും overlay വിലാസമുണ്ട്, ഉപകരണം നെറ്റ്വർക്കുകൾക്കിടയിൽ നീങ്ങുമ്പോഴും അത് സ്ഥിരമായിരിക്കും. ആ വിലാസമാണ് സർട്ടിഫിക്കറ്റുകളും ഫയർവാൾ നിയമങ്ങളും പിയർ ബന്ധങ്ങളും ഉപയോഗിക്കുന്ന ഐഡന്റിറ്റി, ഒറ്റയ്ക്ക് അത് എങ്ങോട്ടും റൂട്ട് ചെയ്യുന്നില്ല. എത്തിച്ചേരാവുന്ന എൻഡ്പോയിന്റ് മറ്റൊന്നാണ്: അടിസ്ഥാന നെറ്റ്വർക്കിലെ ഹോസ്റ്റ്നാമോ വിലാസമോ കൂടെ ഒരു UDP പോർട്ടും, യന്ത്രം സ്ഥലം മാറുമ്പോഴെല്ലാം അത് മാറുന്നു. സ്ഥിര മാപ്പ് രണ്ടിന്റെയും കൂട്ടുകെട്ടാണ്.

തണുത്ത അവസ്ഥയിൽ ഡയൽ ചെയ്യേണ്ട ഹോസ്റ്റുകൾ മാത്രമാണ് മാപ്പിലേക്ക് വരുന്നത്, സാധാരണയായി ലൈറ്റ്ഹൗസുകളും ഒരുപക്ഷേ ഒരു റിലേയും. ആ പട്ടിക ചെറുതായി സൂക്ഷിക്കുന്നത് ഒരു ഡിസൈൻ ലക്ഷ്യമാണ്, കാരണം ഓരോ കൈയെഴുത്ത് എൻട്രിയും ആരെങ്കിലും പരിപാലിക്കേണ്ട ഒരു വസ്തുതയാകുന്നു. രണ്ട് തരം വിലാസങ്ങൾ കൂട്ടിക്കലർത്തുന്നത് സാധാരണ കോൺഫിഗറേഷൻ പിശകാണ്: ലൈറ്റ്ഹൗസ് പട്ടികയിൽ ഇട്ട ഒരു പൊതു വിലാസം കണ്ടെത്തൽ തുടങ്ങാൻ ഇടയാക്കുന്നില്ല.

ഐഡന്റിറ്റി ഐഡന്റിറ്റി പ്രതീക്ഷിക്കുന്നിടത്തേക്ക് പോകുന്നു. എത്തിച്ചേരൽ മാപ്പിലേക്ക് പോകുന്നു.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

ഒരു മാപ്പ് എൻട്രിയുടെ ഘടന

കീ ഉദ്ധരണികൾക്കിടയിലുള്ള സ്ട്രിംഗായി എഴുതിയ overlay വിലാസമാണ്, മൂല്യം എൻഡ്പോയിന്റുകളുടെ പട്ടികയാണ്, അതിനാൽ ഒരു ഐഡന്റിറ്റിക്ക് നിരവധി പ്രവേശന കേന്ദ്രങ്ങൾ ഉണ്ടാകാം. ഓരോ എൻഡ്പോയിന്റും ഒരു ഹോസ്റ്റും ഒരു പോർട്ടും വഹിക്കുന്നു, പോർട്ട് മറുവശം യഥാർത്ഥത്തിൽ കേൾക്കുന്നതുമായി പൊരുത്തപ്പെടണം. Nebula യുടെ സ്ഥിരസ്ഥിതി UDP 4242 ആണ്, അത് ഒരു തുടക്കമാണ്, നിങ്ങളുടെ വിന്യാസത്തെക്കുറിച്ചുള്ള വാഗ്ദാനമല്ല.

ഒരു ലൈറ്റ്ഹൗസിന് ഒന്നിലധികം പ്രവേശന മാർഗങ്ങൾ ഉള്ളപ്പോൾ നിരവധി എൻഡ്പോയിന്റുകൾ ഉപയോഗപ്രദമാണ്, ഉദാഹരണത്തിന് ഒരു പൊതു വിലാസവും അതേ സെഗ്മെന്റിലെ ഹോസ്റ്റുകൾക്കുള്ള ഒരു സ്വകാര്യ വിലാസവും. ക്ലയന്റ് അവ ക്രമത്തിൽ പരീക്ഷിക്കുന്നു, അതിനാൽ ഏറ്റവും വിശ്വസനീയമായത് ആദ്യം ഇടുക. IPv6 ന് പോർട്ട് ചേർക്കുന്നതിന് മുമ്പ് വിലാസം ചതുര ബ്രാക്കറ്റിൽ ഇടുക; തെറ്റ് ചെയ്താൽ തെറ്റായ വരിയിലേക്ക് ചൂണ്ടുന്ന പാർസ് പിശക് ഉണ്ടാകും.

തെറ്റായ പോർട്ട് പിശകിന് പകരം നിശ്ശബ്ദത നൽകുന്നു, കാരണം UDPക്ക് നിരസിക്കാൻ ഒരു ഹാൻഡ്ഷേക്ക് ഇല്ല. അതിനാൽ എൻട്രിയുടെ ഫോർമാറ്റ് Nebula static_host_map റഫറൻസുമായി പരിശോധിക്കുന്നത് മൂല്യമുള്ളതാണ്, ഓർമ്മയുമായി അല്ല. റഫറൻസ് എൻഡ്പോയിന്റ് പട്ടികകളും DNS പുതുക്കലിന്റെ സ്വഭാവവും ഉൾക്കൊള്ളുന്നു.

overlay-ന് മുമ്പ് ബൂട്ട്സ്ട്രാപ്പ് പ്രവർത്തിക്കണം

മാപ്പിലെ DNS നാമം ഏതെങ്കിലും ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പ് ഹോസ്റ്റിനുള്ള റിസോൾവർ വഴി പരിഹരിക്കപ്പെടണം, അതായത് സാധാരണ സിസ്റ്റം റിസോൾവർ. അതേ യന്ത്രത്തിൽ നിന്ന്, ബൂട്ട് സമയത്ത്, overlay നിർത്തിവച്ച് പരീക്ഷിക്കുക. overlay-ന്റെ സ്വന്തം DNS വഴി മാത്രം പരിഹരിക്കുന്ന ഒരു നാമത്തിന് overlay ബൂട്ട്സ്ട്രാപ്പ് ചെയ്യാനാവില്ല. അതേ പരീക്ഷണം റൂട്ടിനും ബാധകമാണ്: overlay അനുവദിക്കുകയും എന്നാൽ ആദ്യ UDP കൈമാറ്റം അനുവദിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഫയർവാൾ നിയമം പ്രാരംഭ പാക്കറ്റ് തടയുന്നു.

പോർട്ട് തുറന്നിരിക്കുന്നുവെന്ന് അനുമാനിക്കുന്നതിന് പകരം UDP ഉപകരണം ഉപയോഗിച്ച് പരിശോധിക്കുക. പാതയിലെ ഏതെങ്കിലും പോർട്ട് ഫോർവേഡിംഗ് ശരിയായ ആന്തരിക ഹോസ്റ്റിനെ ലക്ഷ്യമിടുന്നുവെന്നും തിരിച്ചുവരവ് പാതയുണ്ടെന്നും സ്ഥിരീകരിക്കുക. ഹോസ്റ്റ്നാം നിരവധി വിലാസങ്ങളിലേക്ക് പരിഹരിക്കപ്പെടുന്നുവെങ്കിൽ ഓരോന്നും പരീക്ഷിക്കുക, കാരണം നിങ്ങൾ ഒരിക്കലും പരിശോധിക്കാത്ത ഒരു വിലാസം ക്ലയന്റ് തിരഞ്ഞെടുത്തേക്കാം.

സ്ഥിര എൻട്രികൾ നേരിട്ട് ഡയൽ ചെയ്യപ്പെടുന്നു, ഒരിക്കലും ഒരു ലൈറ്റ്ഹൗസിനോട് ആലോചിക്കുന്നില്ല. അതിനാൽ ഇവിടെയുള്ള പരാജയം ഒരു പിയറും ഇല്ലാത്ത സാധാരണ ടൈംഔട്ട് പോലെ തോന്നുന്നു.

ആദ്യ ഹാൻഡ്ഷേക്കിന് ശേഷം എന്ത് സംഭവിക്കുന്നു

ഒരു ഹോസ്റ്റ് ലൈറ്റ്ഹൗസിൽ എത്തിയാൽ കൂടുതൽ കൈയെഴുത്ത് എൻട്രികളില്ലാതെ പിയറുകളെയും അവരുടെ എത്തിച്ചേരാവുന്ന വിലാസങ്ങളെയും കുറിച്ച് അറിയുന്നു. അവസാന കണക്ഷന് ശേഷം നീങ്ങിയ ഹോസ്റ്റുകൾ ആ ചാനലിലൂടെ കണ്ടെത്താവുന്നതാകുന്നു. കൈയെഴുത്ത് മാപ്പ് ചെറുതായി സൂക്ഷിക്കുന്നതിന്റെ പ്രതിഫലമാണത്.

ഹോസ്റ്റുകൾക്ക് അവരുടെ അധിക എത്തിച്ചേരാവുന്ന വിലാസങ്ങൾ പ്രഖ്യാപിക്കാനും കഴിയും, അങ്ങനെ അറിയപ്പെടുന്ന ഒരു പൊതു വിലാസത്തിന് പിന്നിലുള്ള പിയർ മറ്റുള്ളവരെ അത് കണ്ടെത്താൻ സഹായിക്കുന്നു. ആ പ്രഖ്യാപനങ്ങൾ പഠിക്കപ്പെടുന്നു, സ്ഥിര മാപ്പിൽ എഴുതപ്പെടുന്നില്ല.

DNS നാമങ്ങളായി എഴുതിയ എൻഡ്പോയിന്റുകൾക്ക് പുതുക്കൽ സ്വഭാവം പ്രധാനമാണ്, കാരണം പ്രക്രിയ തുടരുന്നതിനിടയിൽ പരിഹരിച്ച വിലാസം മാറാം. Nebula യുടെ ക്രമീകരണങ്ങൾ ആ തിരച്ചിലുകൾ എങ്ങനെ നടക്കുന്നു, ഏത് റിസോൾവർ ഉപയോഗിക്കുന്നു എന്നതുവരെ നിയന്ത്രിക്കുന്നു, അതിനാൽ സിസ്റ്റം സ്ഥിരസ്ഥിതി അനുമാനിക്കാതെ അവ വായിക്കുക. ടണൽ ഉയരുമ്പോൾ റിസോൾവർ മാറുന്ന ഹോസ്റ്റിൽ, തെറ്റായ ക്രമീകരണം പ്രവർത്തിക്കുന്ന ബൂട്ട്സ്ട്രാപ്പിനെ സെഷന്റെ നടുവിൽ പരിഹരിക്കുന്നത് നിർത്തുന്ന ഒരു നാമമാക്കി മാറ്റാം. തിരച്ചിൽ സ്ഥിരതയുള്ള ഒരു റിസോൾവറിലേക്ക് പിൻ ചെയ്യുന്നത് വിശ്വസനീയമായ overlay-ഉം ഇടയ്ക്കിടെ നിലയ്ക്കുന്ന overlay-ഉം തമ്മിലുള്ള വ്യത്യാസമാണ് പലപ്പോഴും.

കണ്ടെത്തൽ പ്രവർത്തിക്കുമ്പോൾ ഒരു പിയർ പ്രവർത്തിക്കാതിരിക്കുമ്പോൾ

ലൈറ്റ്ഹൗസുകൾ എത്തിച്ചേരാവുന്നതും മിക്ക പിയറുകളും കണക്ട് ചെയ്യുന്നതുമാണെങ്കിൽ ബൂട്ട്സ്ട്രാപ്പ് പ്രശ്നമല്ല. ബാക്കിയുള്ള ജോടി പരസ്പരം ഉപയോഗയോഗ്യമായ ഒരു പാത കണ്ടെത്തുന്നില്ല, അല്ലെങ്കിൽ എത്തിച്ചേരലിന് മുകളിൽ പരാജയപ്പെടുന്നു. ലൈറ്റ്ഹൗസ് വിലാസത്തിന്റെ മറ്റൊരു അക്ഷരവിന്യാസം ചേർക്കുന്നത് രണ്ട് കേസുകളിൽ ഒന്നിനെയും ശരിയാക്കുന്നില്ല.

ബാക്കിയെല്ലാം ഇതിനകം ആശ്രയിക്കുന്ന മാപ്പ് തിരുത്തുന്നതിന് മുമ്പ് ജോടി പരിശോധിക്കുക. മാപ്പ് മാറ്റം ഓരോ ഹോസ്റ്റിനെയും ബാധിക്കുന്നു, അതിനാൽ അത് ഏറ്റവും അവസാനം തൊടേണ്ടതാണ്, ആദ്യം അല്ല.

ഒരേ അതോറിറ്റിയുടെ സർട്ടിഫിക്കറ്റുകളിൽ തുടങ്ങുക, കാരണം നിരസിക്കപ്പെട്ട ഹാൻഡ്ഷേക്ക് ദൂരെ നിന്ന് എത്തിച്ചേരാനാവാത്ത പിയർ പോലെ തോന്നാം. തുടർന്ന് ജോടിക്ക് നേരിട്ടുള്ള പാത സ്ഥാപിക്കാനാകുമോ, നേരിട്ടുള്ള ട്രാഫിക് നിരസിക്കുന്ന നെറ്റ്വർക്കുകൾക്കായി റിലേ ക്രമീകരിച്ചിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക. റിലേ ഒരു ഹോപ്പും ഒരു ആശ്രിതത്വവും ചേർക്കുന്നു, പക്ഷേ അത് പിന്തുണയ്ക്കുന്ന ഉത്തരമാണ്, ജോടിയുടെ പാത ശരിയാക്കുന്നത് കണ്ടെത്തൽ ശരിയാക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ജോലിയാണ്.