OpenVPN സെർവർ കോൺഫിഗറേഷൻ ശാഖയിലേക്ക് പകർത്തുന്നത് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

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

ശാഖയെ സ്വന്തം ഐഡന്റിറ്റിയും നെറ്റ്വർക്ക് റോളുമുള്ള പിയർ ആയി കാണുന്നതാണ് പ്രൊഫൈലിനെ ശരിയാക്കുന്നത്. പരിഹാരം മികച്ച പകർപ്പല്ല, ഈ പേജിന്റെ ബാക്കി ഒരു ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്ത് സൂക്ഷിക്കണം എന്നതിനെക്കുറിച്ചാണ്.

ഒരു ഫയൽ പോലെ തോന്നുന്ന രണ്ട് റോളുകൾ

TLS മോഡിൽ ഇരു വശങ്ങളുടെയും ജോലികൾ പരസ്പരം പൂരകമാണ്. ഒരു വശം ശ്രവിക്കുന്നു, സെർവർ സർട്ടിഫിക്കറ്റും കീയും സൂക്ഷിക്കുന്നു, ഏത് ക്ലയന്റുകൾക്ക് കണക്ട് ചെയ്യാമെന്ന് തീരുമാനിക്കുന്നു. മറുവശം ആരംഭിക്കുന്നു, ശ്രോതാവിനെ പരിശോധിക്കുന്നു, സ്വന്തം ഐഡന്റിറ്റി അവതരിപ്പിക്കുന്നു.

സെർവർ ഫയലിൽ ക്ലയന്റിൽ അർത്ഥമില്ലാത്ത നിർദ്ദേശങ്ങൾ ഉണ്ട്: ശ്രവിക്കാൻ ഒരു ബൈൻഡ് വിലാസവും പോർട്ടും, വിതരണം ചെയ്യാൻ വിലാസങ്ങളുടെ ഒരു പൂൾ, പലപ്പോഴും ക്ലയന്റുകൾക്ക് ലഭിക്കേണ്ട ക്രമീകരണങ്ങൾക്കുള്ള ഒരു പുഷ് ലിസ്റ്റും. അവ ശാഖയിലേക്ക് പകർത്തുന്നത് ഒരേ സമയം ശ്രോതാവും ക്ലയന്റും ആകാൻ ശ്രമിക്കുന്ന ഒരു ഉപകരണം സൃഷ്ടിക്കുന്നു.

ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗം സ്വകാര്യ കീയാണ്. ക്ലയന്റ് ഒരിക്കലും സെർവറിന്റെ സ്വകാര്യ കീ വഹിക്കരുത്, CA യുടെ ഒപ്പ് കീയും അതിന് ആവശ്യമില്ല. CA സർട്ടിഫിക്കറ്റ് പൊതു വിശ്വാസ വസ്തുവാണ്; ഒപ്പ് കീ സർട്ടിഫിക്കറ്റുകൾ നൽകുന്ന സ്ഥലത്തിന് സ്വന്തമാണ്.

ശാഖാ പ്രൊഫൈലിൽ എന്ത് ഉണ്ടാകണം

ശാഖാ പ്രൊഫൈലിന് വിദൂര എൻഡ്പോയിന്റും ഗതാഗതവും, വിശ്വസനീയമായ സെർവർ ഐഡന്റിറ്റിയും, ശാഖയുടെ സ്വന്തം സർട്ടിഫിക്കറ്റും കീയും, ശാഖയ്ക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള റൂട്ടുകളും DNS ക്രമീകരണങ്ങളും വേണം. മറ്റൊന്നും നിർബന്ധമല്ല.

ഓരോ സൈറ്റിനും ശാഖയുടെ ഐഡന്റിറ്റി വെവ്വേറെ സൂക്ഷിക്കുക. രണ്ട് ശാഖകൾ ഒരു സർട്ടിഫിക്കറ്റ് പങ്കിട്ടാൽ ഒന്ന് റദ്ദാക്കുന്നത് മറ്റൊന്നിനെ പ്രവർത്തനരഹിതമാക്കുന്നു, ഹബ്ബിന്റെ ലോഗുകൾക്ക് അവയെ വേർതിരിക്കാനാവില്ല. സൈറ്റ് അനുസരിച്ചുള്ള ഐഡന്റിറ്റിയാണ് ഓഡിറ്റ് ട്രെയിലും റദ്ദാക്കൽ കഥയും പ്രവർത്തിപ്പിക്കുന്നത്.

ഉപകരണ വർക്ക്ഫ്ലോകളിൽ ശ്രദ്ധിക്കുക. pfSense ന്റെ Client Export പാക്കേജ് യോഗ്യമായ Remote Access സന്ദർഭങ്ങൾക്ക് പ്രൊഫൈലുകൾ നിർമ്മിക്കുന്നു, അതിന്റെ സെർവർ ലിസ്റ്റിൽ Remote Access മോഡിൽ കോൺഫിഗർ ചെയ്ത സെർവറുകൾ മാത്രമാണ്. മറ്റൊരു മോഡിലെ സൈറ്റ്-ടു-സൈറ്റ് സെർവർ പ്രത്യക്ഷപ്പെടുന്നില്ല, ആ അഭാവം വിവരമാണ്, സെർവറിന്റെ രഹസ്യങ്ങൾ പകർത്താനുള്ള ക്ഷണമല്ല.

ഉപകരണം ആവശ്യമായ പ്രൊഫൈൽ കയറ്റുമതി ചെയ്യുന്നില്ലെങ്കിൽ, അതിന്റെ രേഖപ്പെടുത്തിയ സൈറ്റ്-ടു-സൈറ്റ് ക്ലയന്റ് വർക്ക്ഫ്ലോ ഉപയോഗിക്കുക അല്ലെങ്കിൽ ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിന്റെ പിന്തുണയുള്ള ഉദാഹരണത്തിൽ നിന്ന് പ്രൊഫൈൽ നിർമ്മിക്കുക. സെർവർ ബാക്കപ്പ് ശാഖയിലേക്ക് കയറ്റുമതി ചെയ്യേണ്ടത് പദ്ധതി സെർവർ പുനഃസ്ഥാപിക്കലാണെങ്കിൽ മാത്രമാണ്, അതല്ല ഇവിടെ. ബാക്കപ്പ് ഹബ്ബിന്റെ സ്വകാര്യ വസ്തുവും വഹിക്കുന്നു, അതിനാൽ ഒന്ന് ശാഖയിലേക്ക് മാറ്റുന്നത് കീ കൈകാര്യം ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള തീരുമാനമാണ്, ഫയൽ കൈമാറ്റമല്ല. അത് ഹബ്ബിൽ സൂക്ഷിക്കുക, ക്ലയന്റ് ഐഡന്റിറ്റി സർട്ടിഫിക്കറ്റുകൾ നൽകുന്നിടത്ത് സൃഷ്ടിക്കുക.

പിയർ-നെറ്റ്വർക്ക് ബന്ധം വേറിട്ടതാണ്

വിജയകരമായി കണക്ട് ചെയ്യുന്ന ശാഖാ ക്ലയന്റിന് ഇപ്പോഴും സ്വന്തം LAN-നുള്ള ട്രാഫിക് കടത്തിവിടാനാവില്ല, ഈ പിയർ ആ പ്രിഫിക്സിന്റെ ഉടമയാണ് എന്ന് ഹബ് അറിയുന്നതുവരെ. ആ ബന്ധം ഹബ്ബിൽ ജീവിക്കുന്നു, ക്ലയന്റിന്റെ ഐഡന്റിറ്റിയുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, ശാഖയുടെ സ്വന്തം വിദൂര നെറ്റ്വർക്കുകളിലേക്കുള്ള റൂട്ടിൽ നിന്ന് വേറിട്ടതാണ്. അതില്ലാതെ ശാഖയിലെ ഹോസ്റ്റുകൾ ടണലിന്റെ സ്ഥിതിവിവരക്കണക്കുകളിൽ എത്താവുന്നതായി തോന്നുന്നു, പ്രായോഗികമായി എത്താനാവില്ല. ബന്ധം പ്രയോഗിച്ചോ എന്ന് സ്ഥിരീകരിക്കുന്നത് ഹബ്ബ് ലോഗിലാണ്.

ഹബ്ബിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ ഒരു റൂട്ട് ചേർക്കുന്നത് OpenVPN-നോട് ഏത് ക്ലയന്റാണ് പ്രിഫിക്സിന്റെ ഉടമ എന്ന് പറയുന്നതിന് തുല്യമല്ല. ഓരോ ക്ലയന്റിനുമുള്ള ബന്ധമില്ലാതെ പാക്കറ്റ് ടണൽ ഇന്റർഫേസിൽ എത്തി ഉപേക്ഷിക്കപ്പെടുന്നു, കാരണം ഒരു പിയറും ലക്ഷ്യസ്ഥാനം അവകാശപ്പെടുന്നില്ല.

ശാഖയുടെ ഭാഗത്ത് ബന്ധപ്പെട്ട ആവശ്യം എത്തിച്ചേരേണ്ട നെറ്റ്വർക്കുകളിലേക്കുള്ള റൂട്ടും, ട്രാഫിക് ശാഖയിലേക്ക് തിരികെ അയയ്ക്കാൻ അറിയുന്ന ഒരു LAN റൂട്ടറുമാണ്. സെർവർ ഭാഗത്തെ ഉടമസ്ഥതയും ക്ലയന്റ് ഭാഗത്തെ ലക്ഷ്യ റൂട്ടുകളും വെവ്വേറെ വസ്തുക്കളാണ്, പ്രവർത്തിക്കുന്ന ടണൽ ആദ്യ ചാട്ടം മാത്രം തെളിയിക്കുന്നു. രണ്ടും ശാഖയുടെ കൈമാറ്റ കുറിപ്പുകളിൽ എഴുതുക, അടുത്ത എൻജിനീയർ അവയിൽ ഒന്ന് മാത്രമേ കണ്ടെത്തൂ.

ശാഖ നിങ്ങൾ കരുതുന്ന പിയർ തന്നെയെന്ന് തെളിയിക്കുക

ട്രാഫിക് പരിശോധിക്കുന്നതിന് മുമ്പ് ഐഡന്റിറ്റി പരിശോധിക്കുക. ഹബ്ബ് ലോഗിൽ ശാഖയുടെ സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമം കാണണം, ക്ലയന്റിന് ലഭിച്ച വിലാസം നിങ്ങൾ ഉദ്ദേശിച്ച പൂളുമായോ സ്ഥിര അനുവദനീയതയുമായോ പൊരുത്തപ്പെടണം. ലോഗിൽ മറ്റൊരു പേര് കാണുന്നുവെങ്കിൽ പ്രൊഫൈൽ മറ്റൊരാളുടെ ഐഡന്റിറ്റി വഹിക്കുന്നു.

തുടർന്ന് ശാഖയിലെ ഒരു ഹോസ്റ്റിൽ നിന്ന് ഹബ്ബ് ഭാഗത്തെ ഒരു റിസോഴ്സിലേക്ക് ഒരു അഭ്യർത്ഥന അയച്ച് ബന്ധം പരിശോധിക്കുക, പ്രതീക്ഷിച്ച ഉറവിട വിലാസത്തോടെ അത് വിജയിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. ശാഖ എത്തരുതാത്ത ഒരു ലക്ഷ്യസ്ഥാനം പരീക്ഷിച്ച് അത് പരാജയപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, കാരണം യാദൃശ്ചികമായി പ്രവർത്തിക്കുന്ന ഒരു അനുവദനീയ റൂട്ട് ശരിയായ നയത്തിന് തുല്യമല്ല.

അവസാനം ശാഖയുടെ ഐഡന്റിറ്റി റദ്ദാക്കുക, ഹബ്ബിന്റെ സ്വന്തം സർട്ടിഫിക്കറ്റും മറ്റ് സൈറ്റുകളും പ്രവർത്തിക്കുമ്പോൾ കണക്ഷൻ പരാജയപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. റദ്ദാക്കൽ ഹബ്ബിനെ തകർക്കുന്നുവെങ്കിൽ റോളുകളും ഐഡന്റിറ്റികളും എവിടെയോ പങ്കിട്ടിരുന്നു, അതാണ് ഡിസൈനിലേക്ക് തിരികെ കൊണ്ടുപോകാൻ യോഗ്യമായ കണ്ടെത്തൽ.

പൂർത്തിയായ ശാഖ എന്നത് രേഖപ്പെടുത്തിയ ഐഡന്റിറ്റി, ക്ലയന്റിന് മാത്രമുള്ള പ്രൊഫൈൽ, ഹബ്ബിലെ പിയർ-നെറ്റ്വർക്ക് ബന്ധം, പരീക്ഷിച്ച മടങ്ങിവരവ് പാത എന്നിവയുള്ള ശാഖയാണ്. സെർവർ ഫയലിലെ വാചകം തിരിച്ചിടുന്നത് അവയിൽ ഒന്നും നിങ്ങൾക്ക് നൽകുന്നില്ല.