openfortivpn കണക്ട് ചെയ്യുമ്പോൾ റൂട്ടുകളുടെയും DNS-ന്റെയും ഉടമസ്ഥൻ ആരായിരിക്കണം?

പ്രവർത്തിക്കുന്ന openfortivpn സെഷനിൽ നാല് ഘട്ടങ്ങൾ ഒന്നിനു മേൽ ഒന്നായി അടുക്കുന്നു. ക്ലയന്റ് ഗേറ്റ്വേയിൽ പ്രാമാണീകരിക്കുകയും TLS കണക്ഷൻ ആരംഭിക്കുകയും ചെയ്ത്, പിന്നീട് ആ കണക്ഷനുള്ളിൽ PPP പ്രവർത്തിപ്പിക്കുന്നു, തുടർന്ന് വിലാസവും DNS വിവരവും സ്വീകരിക്കുന്നു, ഒടുവിൽ ഹോസ്റ്റ് റൂട്ടുകളും റിസോൾവർ ക്രമീകരണങ്ങളും പ്രയോഗിക്കുന്നു. അടുത്തത് ഇല്ലാതിരിക്കുമ്പോഴും ഓരോ ഘട്ടവും സജീവമായിരിക്കാം, അതുകൊണ്ടാണ് “കണക്ട് ചെയ്തു” എന്നത് സപ്പോർട്ട് ത്രെഡുകളിൽ ഇത്ര വഴുതുന്ന വാക്ക്.

ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പം ഒഴിവാക്കുന്ന തീരുമാനം അവസാന ഘട്ടത്തിന്റെ ഉടമ ആരാണെന്നതാണ്. ഒന്നുകിൽ VPN ക്ലയന്റ് തന്നെ ഹോസ്റ്റ് മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നു, അല്ലെങ്കിൽ മറ്റൊരു ഘടകം അത് ചെയ്യുന്നു, രണ്ടും പകുതി വഴിയിൽ കലർത്തുന്നതാണ് റൂട്ടുകളും റിസോൾവർ ഫയലുകളും വ്യത്യസ്ത സെഷനുകളെ വിവരിക്കാൻ കാരണം.

ഒരു കണക്ഷൻ പോലെ തോന്നുന്ന നാല് ഘട്ടങ്ങൾ

ആദ്യ ഘട്ടം പ്രവേശനമാണ്. പേരുള്ള പ്രാമാണീകരണ ഡൊമെയ്ൻ അല്ലെങ്കിൽ ഒറ്റത്തവണ കോഡ് വഴി, തുടരാൻ ആവശ്യമായ പാരാമീറ്ററുകൾ സ്വീകരിക്കുന്നു. ക്ലയന്റ് ഗേറ്റ്വേയുമായി കണക്ട് ചെയ്തതായി പ്രിന്റ് ചെയ്യുമ്പോൾ, TLS ട്രാൻസ്പോർട്ട് സജീവമാണെന്നാണ് അർത്ഥം. PPP ചർച്ച ചെയ്തുവെന്ന് അർത്ഥമില്ല, ഒരു ആന്തരിക അപ്ലിക്കേഷൻ ലഭ്യമാണെന്നും അർത്ഥമില്ല.

രണ്ടാം ഘട്ടം PPP ലിങ്ക് ആണ്. ക്ലയന്റ് ടണൽ ഉപകരണത്തിനെതിരെ ഒരു PPP പ്രക്രിയ ആരംഭിക്കുന്നു, ഇരുവശവും ലിങ്ക് ഓപ്ഷനുകളും വിലാസങ്ങളും ചർച്ച ചെയ്യുന്നു. അതിനുശേഷം മാത്രമാണ് സെഷൻ ഏത് പ്രാദേശിക, ദൂര വിലാസങ്ങൾ ഉപയോഗിക്കുന്നുവെന്ന് ഹോസ്റ്റിന് അറിയുന്നത്, അപ്പോൾ മാത്രമാണ് ടണലിലേക്കുള്ള ഒരു റൂട്ടിന് അർത്ഥമുള്ളത്.

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

റൂട്ടിംഗ് പട്ടിക ആരാണ് തിരുത്തുന്നത്

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

മറ്റെന്തെങ്കിലും യഥാർത്ഥത്തിൽ റൂട്ടിംഗ് സ്വന്തമാക്കുമ്പോൾ മാത്രം കൈമാറ്റം തിരഞ്ഞെടുക്കുക. നെറ്റ്വർക്ക് മാനേജർ സംയോജനം, കണ്ടെയ്നർ നെറ്റ്വർക്ക് നെയിംസ്പേസ്, അല്ലെങ്കിൽ മുഴുവൻ സൈറ്റിലെയും റൂട്ടിംഗ് ഏജന്റ് എന്നിവ അതേ പ്രിഫിക്സുകൾ ഇൻസ്റ്റാൾ ചെയ്ത് വൃത്തിയാക്കാൻ ഇതിനകം അറിഞ്ഞിരിക്കാം. no-routes ഓപ്ഷൻ നൽകുന്നത് രണ്ട് എഴുത്തുകാർ ഒരേ പട്ടികയ്ക്കുവേണ്ടി പോരാടുന്നത് തടയുന്നു, ഇത് ശുദ്ധമായ പരാജയത്തിനുപകരം ഒരു സബ്നെറ്റിന്റെ ഇടയ്ക്കിടെയുള്ള നഷ്ടമായി പ്രത്യക്ഷപ്പെടുന്ന ഒരു മത്സരമാണ്.

ഓവർലാപ്പ് കൈമാറ്റത്തിന്റെ രണ്ടാമത്തെ കാരണമാണ്. തള്ളിയ റൂട്ടുകളിൽ പ്രാദേശിക നെറ്റ്വർക്ക് ഇതിനകം ഉപയോഗിക്കുന്ന ഒരു പ്രിഫിക്സ് ഉണ്ടെങ്കിൽ, ക്ലയന്റിന് നിങ്ങൾക്കുവേണ്ടി സംഘർഷം പരിഹരിക്കാനാവില്ല. ആ പ്രിഫിക്സ് ടണലിലൂടെയോ ഭൗതിക ലിങ്കിലൂടെയോ കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടിലൂടെയോ എത്താമോ എന്ന് ആരെങ്കിലും തീരുമാനിക്കണം, ആ തീരുമാനം ടോപ്പോളജി ഉള്ളവരുടേതാണ്.

വൃത്തിയാക്കൽ മൂന്നാമത്തേതാണ്. തന്റെ റൂട്ടുകൾ നീക്കം ചെയ്യുന്നതിന് മുമ്പ് ക്രാഷ് ചെയ്യുന്ന ക്ലയന്റ് സെഷനേക്കാൾ കൂടുതൽ കാലം ജീവിക്കുന്ന ഒരു കറുത്ത കുഴി അവശേഷിപ്പിക്കുന്നു, അടുത്ത കണക്ഷൻ അതിന് മേൽ ഒരു പകർപ്പ് ചേർത്തേക്കാം. റൂട്ടിംഗ് ഉള്ളവൻ പഴയ എൻട്രികൾ പോയി എന്നുള്ള പരിശോധനയുടെ ഉടമയുമാണ്. ആ പരിശോധന സ്റ്റാർട്ടപ്പ് പാതയുടെ ഭാഗമാക്കുക, ഓപ്ഷണൽ വൃത്തിയാക്കൽ ഘട്ടമല്ല.

DNS-ഉം റിസോൾവർ ഫയലും ആരുടേതാണ്

DNS അതേ തീരുമാനമാണ്, കൂടുതൽ മൂർച്ചയുള്ള അരികുകളോടെ. ഗേറ്റ്വേയോ PPP പങ്കാളിയോ റിപ്പോർട്ട് ചെയ്യുന്ന DNS സെർവറുകൾ ക്ലയന്റിന് സ്വീകരിച്ച് ഹോസ്റ്റ് റിസോൾവർ കോൺഫിഗറേഷനിൽ എഴുതാം. ലളിതമായ യന്ത്രത്തിൽ അതാണ് നിങ്ങൾ ആഗ്രഹിക്കുന്നത്, കാരണം ആന്തരിക നാമങ്ങൾ അപ്പോൾ ടണൽ സജീവമായിരിക്കുമ്പോൾ മാത്രം പരിഹരിക്കപ്പെടുന്നു.

ആധുനിക Linux ഹോസ്റ്റിൽ റിസോൾവർ ഒരു പ്രാദേശിക സ്റ്റബ് കൈകാര്യം ചെയ്തേക്കാം, ആ സ്റ്റബിന്റെ പിന്നിൽ റിസോൾവർ ഫയൽ വീണ്ടും എഴുതുന്നത് ശരിയായി തോന്നുന്നതും എന്നാൽ പൊരുത്തക്കേടോടെ പ്രവർത്തിക്കുന്നതുമായ ഒരു കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുന്നു. ഹോസ്റ്റ് ഇതിനകം ഒരു റിസോൾവർ മാനേജർ പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ, DNS അതിന് സ്വന്തമാക്കാൻ അനുവദിച്ച് അതിന്റെ പിന്തുണയുള്ള ഇന്റർഫേസിലൂടെ ടണലിന്റെ സെർവറുകൾ നൽകുക. ക്ലയന്റിന്റെ no-dns ഓപ്ഷൻ അവിടെ ശരിയായ തിരഞ്ഞെടുപ്പാണ്, ഒരു പകരവഴിയല്ല.

വിഭജിത DNS ഫയൽ ആരാണ് എഴുതുന്നത് എന്നതിൽനിന്ന് വേറിട്ട ചോദ്യമാണ്. ഓരോ ക്വറിയും ടണലിലൂടെ അയയ്ക്കുന്നത് ലളിതവും സാവധാനവുമാണ്; അതിലൂടെ ആന്തരിക സോണുകൾ മാത്രം അയയ്ക്കാൻ ഓരോ ഡൊമെയ്നിനും കോൺഫിഗറേഷൻ വേണം, അത് മിക്ക ലളിത ക്ലയന്റുകളും നൽകുന്നില്ല. ക്ലയന്റിന്റെ റിസോൾവർ മാറ്റങ്ങൾ പ്രവർത്തനക്ഷമമാക്കുന്നതിന് മുമ്പ് ഹോസ്റ്റിന് ഏത് പെരുമാറ്റം വേണമെന്ന് തീരുമാനിക്കുക. ഇവിടെ തെറ്റായ തിരഞ്ഞെടുപ്പ് ടണൽ തന്നെ കുഴപ്പമില്ലെങ്കിലും നാമം പരിഹരിക്കൽ തടസ്സം പോലെ തോന്നും.

പ്രത്യേകാവകാശം, സന്നദ്ധത, കൈമാറ്റം

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

സന്നദ്ധത ഓരോ ഉപഭോക്താവിനും നിർവചിക്കണം. ക്ലയന്റ് പ്രക്രിയ പ്രവർത്തിക്കുകയും ടണൽ ഉപകരണം നിലവിലുണ്ടാകുകയും ചെയ്യുമ്പോൾ സൂപ്പർവൈസർ സേവനം ആരംഭിച്ചതായി കണക്കാക്കാം. ബാക്കപ്പ് ജോലി, അതിന്റെ സംഭരണ എൻഡ്പോയിന്റ് ടണലിലൂടെ ഉത്തരം നൽകുമ്പോൾ മാത്രമേ VPN ഉപയോഗയോഗ്യമായി കണക്കാക്കാവൂ. ഇവ വ്യത്യസ്ത പരിശോധനകളാണ്, ദുർബലമായത് ശക്തമായ ഉദ്ദേശ്യത്തിന് ഉപയോഗിക്കുന്നത് വളരെ നേരത്തെ ആരംഭിച്ച് ഇടയ്ക്കിടെ പരാജയപ്പെടുന്ന ജോലികൾ സൃഷ്ടിക്കുന്നു. തിരഞ്ഞെടുത്ത നിർവചനം എഴുതിവയ്ക്കുക, കാരണം സന്നദ്ധതയെക്കുറിച്ച് യോജിക്കാത്ത സൂപ്പർവൈസറും ജോലിയും സംഭവിക്കാൻ കാത്തിരിക്കുന്ന ഒരു സപ്പോർട്ട് ടിക്കറ്റാണ്.

നാല് നിരീക്ഷണങ്ങളോടെ ഉടമ്പടി പരീക്ഷിക്കുക: ഗേറ്റ്വേ ഘട്ടം പൂർത്തിയാകുന്നു, PPP വിലാസങ്ങൾ അനുവദിക്കുന്നു, ഉദ്ദേശിച്ച റൂട്ട് ഉണ്ട്, ഒരു ആന്തരിക ഹോസ്റ്റിലേക്കുള്ള അഭ്യർത്ഥന വിജയിക്കുന്നു. തുടർന്ന് ക്ലയന്റ് നിർത്തി അവയോരോന്നും നീക്കം ചെയ്യപ്പെട്ടതോ പുനഃസ്ഥാപിക്കപ്പെട്ടതോ ആണെന്ന് ഉറപ്പാക്കുക. ടണൽ അടച്ചതിനുശേഷവും ഹോസ്റ്റ് ആന്തരിക നാമങ്ങൾ പരിഹരിക്കുകയാണെങ്കിൽ അല്ലെങ്കിൽ ഇപ്പോഴും ഒരു റൂട്ട് വയ്ക്കുന്നുണ്ടെങ്കിൽ, ഉടമസ്ഥതാ കൈമാറ്റം അപൂർണമാണ്.