Linux VPN-ൽ വിലാസം, റൂട്ട്, DNS, ഫയർവാൾ എന്നിവയുടെ ഉടമ ആരാണ്?
Linux VPN-ന് ഓരോ വസ്തുവിനും ഒരു അധികാരം വേണം: ഉപകരണം, വിലാസം, റൂട്ടുകൾ, DNS, ഫയർവാൾ. ഈ ഭൂപടം എഴുതുക, തുടർന്ന് ബൂട്ട്, പുനർബന്ധനം, ടിയർഡൗൺ എന്നിവ എന്താണ് പുനഃസ്ഥാപിക്കുന്നതെന്ന് നിർവചിക്കുക.
ഒരേ റൂട്ടിനായി പോരാടുന്ന രണ്ട് സ്ക്രിപ്റ്റുകളാണ് Linux VPN പ്രശ്നത്തിന്റെ സാധാരണ രൂപം, അത് റൂട്ടിംഗ് ബഗ് ആയി രേഖപ്പെടുത്തുന്നു. ഒരു ഘടകം ടണൽ ഉപകരണം സൃഷ്ടിക്കുന്നു, മറ്റൊന്ന് ഡിഫോൾട്ട് റൂട്ട് ചേർക്കുന്നു, മൂന്നാമത്തേത് റിസോൾവർ കോൺഫിഗറേഷൻ വീണ്ടും എഴുതുന്നു, നാലാമത്തേത് ഫയർവാൾ നിയമങ്ങൾ വീണ്ടും ലോഡ് ചെയ്യുന്നു. അവയിലേതെങ്കിലും മറ്റൊന്നിന്റെ ജോലി റദ്ദാക്കാം, വിജയി അവസാനം പ്രവർത്തിച്ചത് മാത്രമാണ്. ഉത്തരം നൽകേണ്ട ചോദ്യം ഏത് പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യണം എന്നതല്ല, മറിച്ച് സ്ഥിതിയുടെ ഓരോ ഭാഗത്തിനും ഏത് ഘടകമാണ് അധികാരമുള്ളത് എന്നതാണ്.
ഈ ഭൂപടം ഒരിക്കൽ എഴുതുക, ഏറിയകൂറും പുനർബന്ധന പരാജയങ്ങൾ നിഗൂഢമല്ലാതാകും. നാല് വസ്തുക്കളാണ് പ്രധാനം: ഉപകരണവും അതിന്റെ വിലാസങ്ങളും, റൂട്ടുകളും നയ നിയമങ്ങളും, DNS കോൺഫിഗറേഷനും ഫയർവാളും.
ഉപകരണവും അതിന്റെ വിലാസങ്ങളും
ടണൽ ഉപകരണം പ്രൊഫൈൽ അറിയുന്ന മാനേജർ സൃഷ്ടിക്കുന്നു, അല്ലെങ്കിൽ ആരോ കൈകൊണ്ട് ആരംഭിച്ച ഡീമൺ സൃഷ്ടിക്കുന്നു. രണ്ട് ക്രമീകരണങ്ങളും സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു; അവ കലർത്തുന്നത് ഇല്ല. NetworkManager പ്രൊഫൈലിന്റെ ഉടമയാണെങ്കിൽ, ഉപകരണത്തിന്റെയും ഉടമയാകട്ടെ, അതേ ടണൽ പേരിനെതിരെ നിയന്ത്രണമില്ലാത്ത OpenVPN പ്രോസസ് ആരംഭിക്കരുത്.
സെഷൻ അവസാനിക്കുമ്പോൾ ഉപകരണം ആരാണ് നീക്കം ചെയ്യുന്നതെന്ന് രേഖപ്പെടുത്തുക. തന്റെ സെഷനെക്കാൾ അധികം ജീവിക്കുന്ന ഉപകരണമാണ് പഴയ വിലാസങ്ങളുടെയും അവയെ തുടർന്നുള്ള ആശയക്കുഴപ്പത്തിന്റെയും ഏറ്റവും സാധാരണ ഉറവിടം.
റൂട്ടുകളും നയ നിയമങ്ങളും
റൂട്ടുകളിൽ തന്നെയാണ് ഉടമസ്ഥതാ സംഘർഷങ്ങൾ കാണാവുന്ന നാശം വരുത്തുന്നത്. ഒരു കണക്ഷൻ മാനേജർ ടണലിന് ഡിഫോൾട്ട് റൂട്ടും ദൂരെയുള്ള നെറ്റ്വർക്കിന് കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നു; തുടർന്ന് കൈകൊണ്ട് എഴുതിയ സ്ക്രിപ്റ്റ് മറ്റൊരു മെട്രിക് ഉപയോഗിച്ച് സ്വന്തം ഡിഫോൾട്ട് ചേർക്കുന്നു, സമയത്തെ ആശ്രയിച്ച് നിശ്ശബ്ദമായി ജയിക്കുകയോ തോൽക്കുകയോ ചെയ്യുന്നു. ഏത് എൻട്രികൾ കണക്ഷനുമായി ബന്ധപ്പെട്ടതാണ്, ഏതാണ് സ്ഥിരമായ നയം, ഏത് ഘടകമാണ് പുനർബന്ധനത്തിന് ശേഷം അവ പുതുക്കുന്നത് എന്ന് തീരുമാനിക്കുക. തുടർന്ന് മറ്റ് ഘടകങ്ങളെ ആ പട്ടികയ്ക്ക് പുറത്ത് നിർത്തുക.
നയ നിയമങ്ങൾക്കും അതേ വ്യക്തത അർഹതയുണ്ട്, കാരണം ആരും നിറയ്ക്കാത്ത ഒരു പട്ടികയിലേക്ക് ചൂണ്ടുന്ന നിയമം ഒരു മരിച്ച ടണലിനെ ഒരുപോലെയിരിക്കുന്ന ഒരു കറുത്ത ദ്വാരം സൃഷ്ടിക്കുന്നു. ട്രാഫിക്കിനെ എവിടേക്കെങ്കിലും തള്ളാൻ ഒരു നിയമം ഉണ്ടെങ്കിൽ, അത് തിരഞ്ഞെടുക്കുന്ന പട്ടിക അതേ ഉടമ തന്നെ പരിപാലിക്കണം.
DNS എപ്പോഴും വേറിട്ട ഉടമയാണ്
റിസോൾവർ ഡീമൺ സ്വന്തം ഐഡന്റിറ്റിയിൽ സ്വന്തം പ്രോസസായി പ്രവർത്തിക്കുന്നു, അതിനാൽ ടണലിന്റെ റൂട്ടിംഗ് തീരുമാനങ്ങൾ അത് യാദൃച്ഛികമായി പാരമ്പര്യമായി സ്വീകരിക്കുന്നില്ല. VPN DNS സർവറുകൾ തള്ളുമ്പോൾ, എന്തെങ്കിലും അതിനെ റിസോൾവർ ബഹുമാനിക്കുന്ന ഓരോ ലിങ്ക് കോൺഫിഗറേഷനായി പരിഭാഷപ്പെടുത്തണം, പിന്നീട് എന്തെങ്കിലും അത് നീക്കം ചെയ്യണം.
ഇവിടെയുള്ള കെട്ടുകഥ, പ്രൊഫൈലിൽ ഒരു നെയിംസർവർ എഴുതുന്നത് ക്വറികൾ എവിടേക്ക് പോകുന്നു എന്നത് മാറ്റുന്നു എന്നതാണ്. അത് റിസോൾവറിനോട് പറയുന്നത് മാറ്റുന്നു, റിസോൾവർ അപ്സ്ട്രീമിൽ ഏത് സോക്കറ്റ് ഉപയോഗിക്കുന്നു എന്നതല്ല. ഫയലിനെ വിശ്വസിക്കുന്നതിന് പകരം ഒരു ക്വറിയും റൂട്ട് ലുക്കപ്പും ഉപയോഗിച്ച് പരിശോധിക്കുക.
ഫയർവാൾ സ്ഥിതിയും അത് ആരാണ് പുനഃസ്ഥാപിക്കുന്നത്
VPN ഹോസ്റ്റിൽ ഏറ്റവും കൂടുതൽ വീണ്ടും എഴുതപ്പെടുന്ന വസ്തുവാണ് ഫയർവാൾ നിയമങ്ങൾ. ഓരോ കണക്ഷനും മാനേജർ NAT അല്ലെങ്കിൽ ഫോർവേഡിംഗ് നിയമങ്ങൾ ചേർക്കാം, അതേസമയം ബൂട്ട് സമയത്തെ ഫയർവാൾ സേവനം സൂക്ഷിച്ച നിയമക്കൂട്ടം വീണ്ടും ലോഡ് ചെയ്ത് അവ മായ്ക്കുന്നു. നയത്തിന് ഒരു അധികാരം തിരഞ്ഞെടുത്ത് മറ്റൊന്നിനെ അതിന്റെ ഉപഭോക്താവാക്കുക, അല്ലെങ്കിൽ റീബൂട്ട് സ്വഭാവം നിശ്ശബ്ദമായി മാറ്റുന്നു എന്ന് സ്വീകരിക്കുക. കണക്ഷനുമായി ബന്ധപ്പെട്ട ഒഴിവുകൾ അതേ ഉടമ ലോഡ് ചെയ്യുന്ന ഫയലിൽ ആയിരിക്കണം, പ്രശ്നപരിഹാര വേളയിൽ ടൈപ്പ് ചെയ്ത iptables കമാന്റിൽ അല്ല.
നിയമങ്ങൾ പുനർബന്ധനത്തെ അതിജീവിക്കേണ്ടതുണ്ടെങ്കിൽ, അത് വ്യക്തമായി പറയുക. ഇല്ലെങ്കിൽ, അതും പറയുക, കാരണം അടുത്ത എൻജിനീയർ കൂടുതൽ സൗകര്യപ്രദമായ ഉത്തരം അനുമാനിക്കും.
ജീവിതചക്രം: ബൂട്ട്, പുനർബന്ധനം, ടിയർഡൗൺ
ഈ മൂന്ന് നിമിഷങ്ങൾക്കും ഓരോ ഉടമയെ നൽകുക. ബൂട്ടിൽ മുൻവ്യവസ്ഥകൾ എന്താണ് തയ്യാറാക്കുന്നതെന്നും ഏത് ക്രമത്തിലെന്നും തീരുമാനിക്കുക. മൃദു റീസ്റ്റാർട്ടിൽ ഉപകരണം അതിജീവിച്ചേക്കാം, സെഷൻ സ്ഥിതി അല്ല, അതിനാൽ സൃഷ്ടാവിന് പകരം സാധൂകരണക്കാരൻ പ്രവർത്തിക്കണം. ടിയർഡൗണിൽ ഈ കണക്ഷൻ സൃഷ്ടിച്ചത് മാത്രം നീക്കം ചെയ്യുക, കാരണം എല്ലാ റൂട്ടുകളും പുനഃസജ്ജമാക്കുന്നതോ മുഴുവൻ ഫയർവാളും ഒഴിവാക്കുന്നതോ ഒരു ടണൽ സേവനത്തിൽ നിന്ന് ഒഴിവാക്കുന്നതിന് തുല്യമല്ല.
നിരീക്ഷണത്തിനായി ip monitor link address route കേർണൽ മാറ്റങ്ങൾ സംഭവിക്കുമ്പോൾ കാണിക്കുന്നു, പക്ഷേ അത് ഉദ്ദേശ്യമല്ല, സംഭവങ്ങളാണ് റിപ്പോർട്ട് ചെയ്യുന്നത്: നീക്കം ചെയ്ത റൂട്ട് ഏത് പ്രോസസ് അത് നീക്കി എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അതിനെ ഉടമസ്ഥതാ ഭൂപടവുമായി ജോടിയാക്കുക, ആശയക്കുഴപ്പമുള്ള ഷട്ട്ഡൗൺ സ്ഥാനാർത്ഥികളുടെ ചെറിയ പട്ടികയായി മാറും.
ഒഴിവുകൾക്കും വിലയുണ്ട്. സംഘർഷത്തിൽ നിന്ന് രക്ഷപ്പെടാൻ ഒരു മുഴുവൻ ഉപകരണ വിഭാഗത്തെ നിയന്ത്രണമില്ലാത്തതായി അടയാളപ്പെടുത്തുന്നത് ആ സ്ഥിതി ആർക്കും നൽകുന്നില്ല, അത് പരിഹാരമല്ല, ഒരു തീരുമാനമാണ്.