Access Server-ൽ നിന്ന് Community OpenVPN-ലേക്ക്: എന്താണ് വീണ്ടും നിർമ്മിക്കേണ്ടത്

Access Server-ഉം Community OpenVPN-ഉം ഒരേ പ്രോട്ടോക്കോൾ സംസാരിക്കുന്നു, മറ്റൊന്നും ഒരേ രീതിയിൽ അല്ല. ഹാൻഡ്ഷേക്ക്, സൈഫർ ചർച്ച, ടണലിന്റെ ഡാറ്റാ പ്ലെയിൻ എന്നിവ പൊരുത്തപ്പെടുന്നു, അതിനാൽ ക്ലയന്റിന് പ്രൊഫൈൽ മാറ്റാതെ തന്നെ ഇരുവശത്തും ബന്ധിപ്പിക്കാം. വ്യത്യാസം കോൺഫിഗറേഷന്റെ ഉടമസ്ഥതയിലാണ്: ഒരു ഉൽപ്പന്നം നയം എഴുതുകയും നടപ്പാക്കുകയും ചെയ്യുന്ന മാനേജ്മെന്റ് പാളി നൽകുന്നു, മറ്റൊന്ന് ഒരു കോൺഫിഗറേഷൻ ഫയലും കുറച്ച് ഹുക്കുകളും നൽകി നിങ്ങൾ തീരുമാനിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു.

ആ വ്യത്യാസമാണ് മൈഗ്രേഷൻ പ്ലാൻ. പഴയ ഉൽപ്പന്നം നിങ്ങൾക്കുവേണ്ടി തീരുമാനിച്ചതെല്ലാം പുതിയ വിന്യാസത്തിൽ എവിടെയെങ്കിലും വ്യക്തമായ തീരുമാനമാകണം.

രണ്ട് വിന്യാസങ്ങളും പരസ്പരം മാറ്റാൻ കഴിയാതാകുന്നിടം

Access Server-ൽ, വെബ് അഡ്മിനിസ്ട്രേഷൻ ഇന്റർഫേസിനാണ് ഉപയോക്താക്കൾ, ഗ്രൂപ്പുകൾ, ഓരോ ഉപയോക്താവിന്റെയും അനുമതികൾ, സർട്ടിഫിക്കറ്റ് നൽകൽ, ഒരാൾ ഡൗൺലോഡ് ചെയ്യുന്ന പ്രൊഫൈൽ ബണ്ടിൽ എന്നിവയുടെ ഉടമസ്ഥത. അതിനടിയിലുള്ള ഡീമോൺ ആ പാളിയാണ് കോൺഫിഗർ ചെയ്യുന്നത്, അതിനാൽ പ്രവർത്തിക്കുന്ന സേവനം കൈകൊണ്ട് അപൂർവ്വമായി തിരുത്തുന്ന സംഭരിച്ച അവസ്ഥയുടെ ഫലമാണ്. Community OpenVPN-ൽ കോൺഫിഗറേഷൻ ഫയലാണ് അവസ്ഥ: അത് ലിസണർ, സർട്ടിഫിക്കറ്റ് അതോറിറ്റി, ഓതന്റിക്കേഷൻ ഹുക്ക്, പുഷ് ചെയ്യുന്ന ഓരോ ഓപ്ഷനും പേരിടുന്നു, ഒന്നും നിങ്ങൾക്കുവേണ്ടി അത് വീണ്ടും എഴുതുന്നില്ല. അതിനാൽ അതേ TLS യന്ത്രം രണ്ട് വളരെ വ്യത്യസ്ത ഉടമസ്ഥതാ മാതൃകകൾക്ക് കീഴിൽ നിൽക്കുന്നു.

ചെറിയൊരു മാപ്പിംഗ് വിടവ് വ്യക്തമാക്കുന്നു. ഉപയോക്താക്കളും ഗ്രൂപ്പുകളും പുതിയതായി സൃഷ്ടിക്കുന്നതുവരെ പഴയ ഡാറ്റാബേസിൽ മാത്രം നിലനിൽക്കുന്നു. പ്രൊഫൈൽ ബണ്ടിലുകൾ ഒരു കോൺഫിഗറേഷൻ ഫയലും നിങ്ങൾ തന്നെ വിതരണം ചെയ്യുന്ന സർട്ടിഫിക്കറ്റുകളും ആകുന്നു. ഓരോ ഉപയോക്താവിന്റെയും അനുമതികൾ client-config-dir-ലെ നിർദ്ദേശങ്ങളാകുന്നു. അഡ്മിനിസ്ട്രേഷൻ ഇന്റർഫേസ് സർട്ടിഫിക്കറ്റ് നൽകാനും ഫയലുകൾ തിരുത്താനും നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പ്രക്രിയയാകുന്നു.

സർവറിൽ തൊടുന്നതിന് മുമ്പ് ആ മാപ്പിംഗ് എഴുതി വയ്ക്കുക. നിങ്ങൾക്ക് പൂരിപ്പിക്കാനാകാത്ത ഓരോ വരിയും നിങ്ങൾ ഇപ്പോൾ നഷ്ടപ്പെടുത്താൻ പോകുന്ന ഒരു സവിശേഷതയാണ്, നിശ്ശബ്ദമായ നഷ്ടമാണ് മൈഗ്രേഷനെ രണ്ടാഴ്ച കഴിഞ്ഞ് തടസ്സമാക്കുന്ന വഴി.

ഐഡന്റിറ്റി സർട്ടിഫിക്കറ്റ് ഫയലുകളോടൊപ്പം കൈമാറ്റം ചെയ്യപ്പെടുന്നില്ല

പഴയ അതോറിറ്റിയുടെ സർട്ടിഫിക്കറ്റുകൾ പുതിയ സേവനത്തിൽ ശരിയായി പാഴ്സ് ചെയ്യപ്പെടാം, എന്നിട്ടും തെറ്റായ ഐഡന്റിറ്റിയാകാം, കാരണം പഴയ ഉൽപ്പന്നം അവയെ പുതിയതിന് കാണാനാകാത്ത അക്കൗണ്ട് അവസ്ഥയുമായി ചേർത്തിരുന്നു. ആദ്യം തീരുമാനിക്കുക: പുതിയ വിന്യാസം സർട്ടിഫിക്കറ്റ് കൊണ്ട് മാത്രം, PAM അല്ലെങ്കിൽ RADIUS-ലേക്ക് എത്തുന്ന പ്ലഗിൻ കൊണ്ട്, അല്ലെങ്കിൽ സംയോജനം കൊണ്ട് ഓതന്റിക്കേറ്റ് ചെയ്യുന്നുണ്ടോ എന്ന്, തുടർന്ന് ഓരോ ഓപ്ഷനും ആവശ്യമായ ഗുണങ്ങൾ നിലനിർത്തുന്നുണ്ടെന്ന് പരിശോധിക്കുക. ഓരോ ഉപയോക്താവിന്റെയും ഐഡന്റിറ്റിയില്ലാത്ത പങ്കിട്ട സർട്ടിഫിക്കറ്റ് അതുള്ള എല്ലാവർക്കും ഒരൊറ്റ ക്രെഡൻഷ്യലാണ്. റദ്ദാക്കലും ആദ്യ ദിവസം മുതൽ പ്രവർത്തിക്കണം, അതായത് Community OpenVPN-ൽ crl-verify റഫർ ചെയ്യുന്ന CRL ഫയലും അത് വീണ്ടും നിർമ്മിക്കുന്ന പ്രക്രിയയും.

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

റൂട്ടിംഗും നാമ വിശകലനവും കോൺഫിഗറേഷൻ എഴുതുന്നയാളെ പിന്തുടരുന്നു

റൂട്ടുകൾ, DNS ക്രമീകരണങ്ങൾ, പൂർണ്ണ ടണൽ സ്വഭാവം എന്നിവ രണ്ട് ഉൽപ്പന്നങ്ങളിലും പുഷ് ചെയ്യപ്പെടുന്ന ഓപ്ഷനുകളാണ്, പക്ഷേ നിങ്ങൾക്കുവേണ്ടി അവ കണക്കാക്കുന്നത് ഒരെണ്ണം മാത്രം. Community OpenVPN-ൽ നിങ്ങൾ തന്നെ പുഷ് നിർദ്ദേശങ്ങൾ എഴുതുന്നു, redirect-gateway സർവറിനാണോ ക്ലയന്റിനാണോ എന്ന് തീരുമാനിക്കുന്നു, ഹോസ്റ്റിൽ ഫോർവേഡിംഗും NAT-ഉം ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നു. പൂർത്തിയായ ഹാൻഡ്ഷേക്ക് ഫോർവേഡിംഗ്, വിലാസ വിവർത്തനം, ക്ലയന്റ് യഥാർത്ഥത്തിൽ സ്വീകരിച്ച റൂട്ടുകൾ എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ഓരോ ക്ലയന്റിന്റെയും സ്വഭാവത്തിന് client-config-dir-ഉം ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന്റെ common name പ്രകാരം പേരിട്ട ഫയലും വേണം, സൈറ്റ്-ടു-സൈറ്റ് ജോടിക്ക് അതിന് പിന്നിലുള്ള പ്രിഫിക്സുകൾക്ക് iroute എൻട്രികളും വേണം. പേര് തെറ്റാണെങ്കിൽ ഓപ്ഷനുകൾ പിശകില്ലാതെ അവഗണിക്കപ്പെടുന്നു. ഉൽപ്പാദനത്തിലല്ലാത്ത ഒരു ക്ലയന്റിനൊപ്പം അതിന്റെ സ്വന്തം വിലാസ പൂളിൽ പരീക്ഷിക്കുക, തുടർന്ന് അതിന് നൽകിയ വിലാസവും ലഭിച്ച റൂട്ടുകളും അവസാനിച്ച റിസോൾവർ ക്രമീകരണങ്ങളും വായിക്കുക.

പഴയ സേവനത്തിന് മടങ്ങിവരാനാകുന്ന വിധത്തിൽ മാറ്റം ക്രമീകരിക്കുക

പുതിയ ലിസണർ മറ്റൊരു പോർട്ടിലോ വിലാസത്തിലോ പ്രവർത്തിപ്പിക്കുക, പകരം വയ്ക്കുന്നത് തെളിയിക്കുന്നതുവരെ പഴയത് ട്രാഫിക് കൈകാര്യം ചെയ്യട്ടെ. ഒരു സോക്കറ്റിൽ രണ്ട് ഡീമോണുകൾ റോൾബാക്ക് പ്ലാനല്ല.

ഒരു സമയം ഒരു ഗ്രൂപ്പ് മാറ്റുക, അതിന്റെ സർട്ടിഫിക്കറ്റുകൾ, പൂൾ, റൂട്ടുകൾ എന്നിവയോടൊപ്പം, സംഭവത്തിനിടയിൽ കണ്ടെത്തുന്നതിന് പകരം മടക്കപ്പാത പരിശീലിക്കുക. പുതിയ സേവനം ആദ്യം നിർത്തിയാൽ മാത്രം പ്രവർത്തിക്കുന്ന റോൾബാക്കും റോൾബാക്കാണ്, പക്ഷേ ഒന്നും കത്താത്തപ്പോൾ അത് പരീക്ഷിക്കണം.

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

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