രണ്ട് സർവറുകളിലായി ഒരു VPN അക്കൗണ്ട്: മൂന്ന് സ്റ്റേറ്റ് ലെഡ്ജറുകൾ
പങ്കിട്ട പ്രവേശനം, നോഡിന് പ്രാദേശികമായ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷൻ, സജീവ സെഷനുകൾ എന്നിവ വെവ്വേറെ പ്രശ്നങ്ങളാണ്. ഒരു അക്കൗണ്ട് നോഡുകൾക്കിടയിൽ പകർത്തുന്നതിന് മുമ്പ് ഇവ വേർതിരിച്ച് വയ്ക്കുക.
രണ്ട് VPN നോഡുകളിൽ ഏതിലും സൈൻ ഇൻ ചെയ്യാൻ കഴിയുന്ന ഒരു അക്കൗണ്ട്, സോഫ്റ്റ്‌വെയർ ചോദ്യമാകുന്നതിന് വളരെ മുമ്പേ ഒരു ഡിസൈൻ ചോദ്യം ഉയർത്തുന്നു. അക്കൗണ്ടിന്റെ കാഴ്ച, ഓരോ നോഡിനും സ്വന്തമായ നെറ്റ്‌വർക്ക്, ബന്ധിപ്പിച്ച ക്ലയന്റ് കൈവശം വയ്ക്കുന്ന സെഷൻ എന്നിവ മൂന്ന് വ്യത്യസ്ത തരം സ്റ്റേറ്റുകളാണ്, അവ ഒരിടത്തുനിന്ന് മറ്റൊരിടത്തേക്ക് പകർത്തുമ്പോൾ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു. മൂന്നും ഒരു സിസ്റ്റത്തിലേക്ക് പകർത്തുന്നത് അവയിലൊന്ന് നഷ്ടപ്പെടുത്താനുള്ള സാധാരണ വഴിയാണ്.
താഴെയുള്ള മൂന്ന് ലെഡ്ജറുകൾ ക്രമത്തിൽ പരിശോധിക്കുക. ഓരോന്നും എന്താണ് അധികാരമുള്ളത്, എന്താണ് പ്രാദേശികം, മറ്റേ നോഡ് ഇല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് ചോദിക്കുന്നു, ഉത്തരങ്ങൾ പരസ്പരം അനുസരിച്ച് വരുന്നില്ല.
ആർക്ക് ബന്ധിപ്പിക്കാം: ഒരു അധികാരം, നിരവധി നോഡുകൾ
പ്രവേശന ലെഡ്ജറിൽ തുടങ്ങുക: ഏത് ഐഡന്റിറ്റി സ്രോതസ്സാണ് അധികാരമുള്ളത്, ഏത് സർട്ടിഫിക്കറ്റ് ഇഷ്യൂവർമാരെ വിശ്വസിക്കുന്നു, ഏത് അക്കൗണ്ടുകൾ യോഗ്യമാണ്, ഏത് രണ്ടാം ഘടകം ബാധകമാണ്, ഓരോ അക്കൗണ്ടും എങ്ങോളം എത്തുന്നു. തുടർന്ന് ഓരോ നോഡും മാറ്റങ്ങൾ എങ്ങനെയും എത്ര വേഗത്തിലും അറിയുന്നു എന്ന് എഴുതുക.
പങ്കിട്ട ഡാറ്റാബേസ് ആ ഉത്തരത്തിന്റെ ഒരു സാധ്യമായ ഘടകമാണ്. ബന്ധപ്പെട്ട എല്ലാ നയങ്ങളും അവിടെയാണെന്നോ എല്ലാ നോഡുകളും ഒരേ നിമിഷത്തിൽ മാറ്റം പ്രയോഗിക്കുന്നുവെന്നോ ഉള്ള തെളിവല്ല അത്. നോഡ് A-യിൽ നിഷ്ക്രിയമാക്കിയെങ്കിലും നോഡ് B-യിൽ ഇപ്പോഴും സ്വീകരിക്കുന്ന അക്കൗണ്ട് എന്നാൽ ഓഫ്‌ബോർഡിംഗ് പ്രക്രിയ പൂർത്തിയായിട്ടില്ല.
അധികാരം ലഭ്യമല്ലാത്തപ്പോൾ നോഡ് എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുക. തടസ്സസമയത്ത് കാഷ് ചെയ്ത ക്രെഡൻഷ്യലുകൾ സ്വീകരിക്കുന്നത് സുരക്ഷാ ചെലവുള്ള നയ തീരുമാനമാണ്, അവ നിരസിക്കുന്നത് ലഭ്യതാ ചെലവുള്ള നയ തീരുമാനമാണ്. രണ്ടും ന്യായീകരിക്കാം; ഡോക്യുമെന്റ് ചെയ്യാതെ വിടുന്നത് അല്ല.
ഇഷ്യൂവറുടെ അധികാരം അക്കൗണ്ട് ഡാറ്റയിൽനിന്ന് വേർതിരിച്ച് വയ്ക്കുക. നിരവധി ഗേറ്റ്‌വേകൾക്ക് അതിന്റെ ഒപ്പിടൽ കീ കൈവശം വയ്ക്കാതെ ഒരേ CA-യെ വിശ്വസിക്കാം, ഓരോ നോഡിനും ഇപ്പോഴും സ്വന്തം സർവർ സർട്ടിഫിക്കറ്റും സ്വന്തം ക്ലയന്റ് ഭാഗത്തെ വിശ്വാസബന്ധവും ആവശ്യമാണ്.
നോഡിനുള്ളത്: വിലാസങ്ങളും പാതകളും
രണ്ടാം ലെഡ്ജർ ഓരോ നോഡിനും പ്രാദേശികമാണ്: കേൾക്കുന്ന വിലാസം, സർവർ ഐഡന്റിറ്റി, വിലാസ പൂൾ, സ്വകാര്യ വിഭവങ്ങളിലേക്കുള്ള റൂട്ടുകൾ, റിസോൾവർ നയം, ട്രാഫിക് ഇന്റർനെറ്റിലേക്ക് എങ്ങനെ പുറത്തുപോകുന്നു. അതേ അക്കൗണ്ട് ഏത് നോഡും സേവിക്കാം, ഈ വസ്തുക്കൾ വേറിട്ടുതന്നെ നിൽക്കുന്നു.
തിരിച്ചുള്ള പാതയാണ് മറക്കപ്പെടുന്ന ഭാഗം. രണ്ട് നോഡുകളും ഒരേ പൂളിൽനിന്ന് വിലാസങ്ങൾ നൽകിയാൽ, സ്വകാര്യ നെറ്റ്‌വർക്കിന് ഒരു നിർദ്ദിഷ്ട ക്ലയന്റ് ഏത് നോഡിന്റേതാണെന്ന് പറയാനാകില്ല, മറുപടി തെറ്റായ സ്ഥലത്തേക്ക് പോകാം. വ്യത്യസ്ത പൂളുകൾക്കും റൂട്ടുകളും അനുമതികളും വേണം, അതിനാൽ വേറിട്ട സംഖ്യാ പരിധി പൂർണ്ണ ഡിസൈനല്ല.
ക്ലയന്റുകളെ ബോധപൂർവം ഒരു നോഡിലേക്ക് അയയ്ക്കുക. DNS തിരഞ്ഞെടുപ്പ്, ക്ലയന്റ് എൻഡ്‌പോയിന്റ് പട്ടികകൾ, ഫ്രണ്ട്-എൻഡ് സേവനം എന്നിവ വ്യത്യസ്ത ആരോഗ്യ-പരാജയ മാറ്റ സ്വഭാവമുള്ള വ്യത്യസ്ത സംവിധാനങ്ങളാണ്. ഒന്ന് തിരഞ്ഞെടുക്കുന്നത് കുഴപ്പമില്ല; “ലോഡ് ബാലൻസിംഗ്” ഡിസൈനായി കണക്കാക്കുന്നത് തിരിച്ചുള്ള പാതയും പരാജയ സ്വഭാവവും നിർവചിക്കാതെ വിടുന്നു.
രേഖപ്പെടുത്തിയ ഒരു ഉൽപ്പന്ന ഉദാഹരണം ഇവിടെ സഹായിക്കുന്നു. Pritunl-ന്റെ പകർപ്പ് രേഖകൾ VPN നെറ്റ്‌വർക്കിനെ ഓരോ പകർപ്പിനുമുള്ള വസ്തുവായി കണക്കാക്കുന്നു, വ്യത്യസ്ത പകർപ്പുകളിലെ ക്ലയന്റുകൾക്ക് പരസ്പരം എത്താൻ അധിക റൂട്ടുകളും കണക്റ്റിവിറ്റിയും വേണം. ഇത് ഉൽപ്പന്നത്തിന് സവിശേഷമായ ക്രമീകരണമാണ്, Community OpenVPN-നുള്ള പാചകക്കുറിപ്പല്ല, പക്ഷേ ഒരു പകർപ്പ് ചേർക്കുന്നത് അക്കൗണ്ട് സ്റ്റോർ മാത്രമല്ല, നെറ്റ്‌വർക്കും മാറ്റുന്നത് എന്തുകൊണ്ടെന്ന് കാണിക്കുന്നു.
സെഷൻ എന്നാൽ എന്ത്: സാലല്ല, ജീവിക്കുന്ന അവസ്ഥ
മൂന്നാം ലെഡ്ജർ സജീവ സെഷനാണ്. ബന്ധിപ്പിച്ച ക്ലയന്റിന് സ്വീകരിച്ച നോഡിൽ പ്രോട്ടോക്കോൾ സ്റ്റേറ്റും നെറ്റ്‌വർക്ക് അനുവദനവും ഉണ്ട്. അക്കൗണ്ട് മറ്റേ നോഡിൽ അറിയാമെന്നത് ആ നോഡിന് സെഷനോ കീകളോ പാക്കറ്റുകൾ തുടരാനുള്ള കഴിവോ നൽകുന്നില്ല.
ഒരു നോഡ് പരാജയപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് വ്യക്തമാക്കുക. പിന്തുണയ്ക്കുന്ന ഫലം പുതിയ പ്രാമാണീകരണത്തോടും പുതിയ വിലാസത്തോടും കൂടി മറ്റേ നോഡിലേക്ക് വീണ്ടും ബന്ധിപ്പിക്കുന്നതാകാം, അതിനുശേഷം അപ്ലിക്കേഷൻ അതിന്റെ രീതിയിൽ കരകയറുന്നു. തടസ്സമില്ലാത്ത കൈമാറ്റം ആവശ്യമെങ്കിൽ, ആ ആവശ്യത്തിന് വ്യക്തമായ നടപ്പാക്കൽ പിന്തുണ വേണം, ഡാറ്റാബേസ് പകർപ്പിൽനിന്നുള്ള അനുമാനമല്ല. ഓൺ-കോൾ എൻജിനീയർക്ക് കണ്ടെത്താനാകുന്ന ഇടത്ത് ഉത്തരം എഴുതുക.
ശേഷി നിയമങ്ങൾക്കും അതേ സമീപനം വേണം. അക്കൗണ്ടിന് രണ്ട് ഒരേസമയ സെഷനുകൾ എന്ന പരിധി നോഡുകൾക്കിടയിൽ നടപ്പാക്കാൻ ഏതെങ്കിലും അധികാരത്തിന് കൈവശപ്പെടുത്തിയ സ്ഥലങ്ങളുടെ ഏകോപിത കാഴ്ച ഉണ്ടെങ്കിൽ മാത്രമേ കഴിയൂ. നോഡ്-പ്രാദേശിക പട്ടികകളും ചരിത്ര അക്കൗണ്ട് രേഖയും ആ കാഴ്ചയായി ചേരുന്നില്ല.
മൂന്ന് ലെഡ്ജറുകൾ പരീക്ഷിക്കൽ
ഓരോന്നും വെവ്വേറെ പരീക്ഷിക്കുക. നോഡ് A വഴി സൈൻ ഇൻ ചെയ്യുക, തുടർന്ന് നോഡ് B വഴി, പ്രതീക്ഷിത വിലാസ പരിധികളോടെ രണ്ടും വിജയിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. ഒരു ഐഡന്റിറ്റി പിൻവലിച്ച് രണ്ട് നോഡുകളും പരിശോധിക്കുക, യാദൃച്ഛികമായി പരീക്ഷിച്ചത് മാത്രമല്ല. തുടർന്ന് ഒരു നോഡ് നിർത്തി ക്ലയന്റും സ്വകാര്യ അപ്ലിക്കേഷനും യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു എന്ന് നിരീക്ഷിക്കുക.
സ്വീകാര്യതാ പരീക്ഷയിൽ തിരിച്ചുള്ള പാത ഉൾപ്പെടുത്തുക. B-യുമായി ബന്ധിപ്പിക്കുന്നെങ്കിലും A-യുടെ പിന്നിലുള്ള ഒരു വിഭവത്തിൽനിന്ന് മറുപടികൾ ലഭിക്കാത്ത ക്ലയന്റ് പ്രവേശന പരിശോധനയിൽ വിജയിച്ച് നെറ്റ്‌വർക്കിൽ പരാജയപ്പെട്ടു, ആ വ്യത്യാസം റിപ്പോർട്ടിൽ വരണം.
മൂന്ന് ലെഡ്ജറുകൾക്കും വ്യക്തമായ ഉടമയും മാറ്റപ്പാതയും പരാജയ സ്വഭാവവും ഉള്ളപ്പോൾ മാത്രമേ ബഹു-നോഡ് അക്കൗണ്ട് ഡിസൈൻ പൂർണ്ണമാകൂ. നോഡുകൾക്കിടയിൽ കോൺഫിഗറേഷൻ ഫയൽ പകർത്തുന്നത് ആ ചോദ്യങ്ങളിലൊന്നിനും ഉത്തരം നൽകുന്നില്ല.