OPNsense-ന് പിന്നിൽ OpenVPN ക്ലയന്റുകളുടെ സ്ഥിര വിലാസങ്ങൾ

പേരുകൾക്ക് ചലിക്കാത്ത വിലാസങ്ങൾ വേണം, OpenVPN-ന്റെ pool ഫയൽ ഒരു വിലാസത്തെ ഒട്ടിപ്പിടിക്കുന്നത് മാത്രം ചെയ്യുന്നു. ആ ഫയൽ നഷ്ടപ്പെട്ടാലോ, മറ്റൊരു പൊതുനാമത്തിൽ സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകിയാലോ, തിരികെ വരുന്ന ക്ലയന്റ് pool-ൽ മറ്റൊരിടത്ത് എത്തുന്നു, അതിന്റെ DNS റെക്കോർഡ് ഇപ്പോഴും പഴയ വിലാസത്തിലേക്കാണ് ചൂണ്ടുന്നത്. നിലനിൽക്കുന്ന ഉത്തരം വിലാസം പിൻ ചെയ്യുന്ന ക്ലയന്റ്-നിർദ്ദിഷ്ട override ആണ്, കൂടെ വിശാലമായ ടണൽ നെറ്റ്വർക്കും, പിൻ ചെയ്ത വിലാസങ്ങൾ ഡൈനാമിക് പരിധിക്ക് പുറത്ത് നിൽക്കാൻ. ആ വിശാലീകരണത്തിന് പിന്നിലെ കണക്കാണ് ആശയക്കുഴപ്പത്തിൽ ഭൂരിഭാഗവും കഴിയുന്നിടം.

OPNsense ഈ override-കൾ സെർവറിന്റെ ക്ലയന്റ്-നിർദ്ദിഷ്ട ക്രമീകരണങ്ങളിൽ സൂക്ഷിക്കുന്നു, സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമം കീയാക്കി, അത് പൊതുനാമത്തെ വിലാസ പദ്ധതിയുടെ ഭാഗമാക്കുന്നു.

ഒട്ടിപ്പിടിക്കുന്ന ലീസ് സ്ഥിര വിലാസമല്ല

pool ഫയൽ വിലാസം-മുതൽ-ക്ലയന്റ് മാപ്പിംഗുകൾ എഴുതുന്നു, അറിയപ്പെടുന്ന ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ അവ തിരികെ നൽകുന്നു. ഇത് സൗകര്യമാണ്, കരാറല്ല: ഫയൽ വീണ്ടും സൃഷ്ടിക്കാം, ക്ലയന്റിന്റെ ഐഡന്റിറ്റി മാറുമ്പോൾ മാപ്പിംഗ് അപ്രത്യക്ഷമാകുന്നു, ഒരേ pool പങ്കിടുന്ന രണ്ട് സെർവറുകൾ അതിൽ യോജിക്കില്ല. ക്ലയന്റ്-നിർദ്ദിഷ്ട override വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, കാരണം വിലാസം ചരിത്രത്തിൽ നിന്നല്ല, കോൺഫിഗറേഷനിൽ നിന്നാണ് വരുന്നത്. ഉപകരണത്തിന്റെ റീസ്റ്റാർട്ടും പുനര്ഇൻസ്റ്റാളും അത് അതിജീവിക്കുന്നു, override ബാക്കിയുള്ള കോൺഫിഗറേഷനോടൊപ്പം ബാക്കപ്പ് ചെയ്തിട്ടുണ്ടെങ്കിൽ.

ഡൈനാമിക് ബദൽ, അതായത് client-connect സ്ക്രിപ്റ്റും ഡൈനാമിക് അപ്ഡേറ്റുകളും ഉപയോഗിച്ച് VPN-നെ DNS-ലേക്ക് ബന്ധിപ്പിക്കുന്നത്, പ്രവർത്തിക്കുന്നു, അപ്ഡേറ്റുകൾ സ്വീകരിക്കുന്ന ഒരു resolver-ഉം ഓരോ കണക്ഷനിലും ഒരു സ്ക്രിപ്റ്റും ആവശ്യമാണ്. ഉപകരണത്തിൽ നിങ്ങൾ വെണ്ടർ നൽകുന്ന പാക്കേജുകളിൽ പരിമിതരാണ്, സാധാരണയായി അവിടെയാണ് ആ പദ്ധതി നിൽക്കുന്നത്.

ആരും ആസ്വദിക്കാത്ത /30 കണക്ക്

സ്ഥിരസ്ഥിതി net30 ടോപ്പോളജിയിൽ ഓരോ ക്ലയന്റും സ്വന്തം /30 നേടുന്നു: ആദ്യ ഉപയോഗയോഗ്യ വിലാസം സെർവർ വശത്തേക്ക് പോകുന്നു, രണ്ടാമത്തേത് ക്ലയന്റിന്. അതിനാൽ override-കൾ സെർവറിന്റെ ഡൈനാമിക് ടണൽ നെറ്റ്വർക്കിന് പുറത്തായിരിക്കണം, അതായത് ആ നെറ്റ്വർക്ക് ആദ്യം വിശാലമാക്കണം. 10.8.0.0/24-ലെ സെർവറിന് 10.8.0.0/23-ലേക്ക് മാറാം, പഴയ പരിധിയുടെ പകുതി ഡൈനാമിക് ക്ലയന്റുകൾക്കും മറ്റേ പകുതി override-കൾക്കും വിട്ടുകൊണ്ട്. യഥാർത്ഥ /24 അധിക IPv4 ലോക്കൽ നെറ്റ്വർക്കായി ചേർക്കുക, ഇരു പകുതികളിലേക്കുമുള്ള ട്രാഫിക് ടണലിലേക്ക് റൂട്ട് ചെയ്യാൻ.

ഓരോ override വിലാസവും /30 അതിരിൽ വീണിരിക്കണം, അതിനാൽ അവസാന ഒക്ടറ്റ് നാലിന്റെ ഗുണിതമാണ്. 10.8.1.0-ലെ /30 ക്ലയന്റിന് 10.8.1.2 നൽകുന്നു, DNS റെക്കോർഡ് വഹിക്കുന്നത് ആ വിലാസമാണ്. പകരം 10.8.1.3 തിരഞ്ഞെടുത്താൽ ബന്ധിപ്പിക്കുന്നുവെങ്കിലും ട്രാഫിക് കടത്തിവിടാൻ കഴിയാത്ത ക്ലയന്റ് ഉണ്ടാകുന്നു, കാരണം ആ വിലാസം ടോപ്പോളജി അതിന് ഒരിക്കലും നൽകാത്ത ഒരു സബ്നെറ്റിന്റേതാണ്.

വിശാലമാക്കിയ പരിധിയുടെ മുകളിൽ നിന്ന് താഴേക്ക് override-കൾ അനുവദിച്ചാൽ പദ്ധതി സൂക്ഷിക്കാൻ എളുപ്പമാണ്, അപ്പോൾ ഡൈനാമിക് pool സ്ഥിര ദ്വീപുകൾക്ക് ചുറ്റുമല്ല, ഒഴിഞ്ഞ ഇടത്തേക്ക് വ്യാപിക്കുന്നു.

ലോക്കൽ നെറ്റ്വർക്കുകളും ക്ലയന്റുകൾ ചോദിക്കുന്ന മേഖലയും

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

ദൂരസ്ഥ ക്ലയന്റുകൾ യഥാർത്ഥത്തിൽ ചോദിക്കുന്ന മേഖലയിൽ റെക്കോർഡുകൾ പ്രസിദ്ധീകരിക്കുക. LAN resolver മാത്രം സേവിക്കുന്ന മേഖലയിലെ റെക്കോർഡ്, പുഷ് ചെയ്ത resolver മറ്റൊരിടത്തേക്ക് ചൂണ്ടുന്ന ക്ലയന്റിന് അദൃശ്യമാണ്, തെറ്റായ മേഖലയിൽ കൂടുതൽ റെക്കോർഡുകൾ ചേർത്താൽ അത് ഒരിക്കലും ശരിയാകുന്നില്ല. എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് പുഷ് ചെയ്ത DNS ഓപ്ഷനും തിരയൽ ഡൊമെയ്നും സ്ഥിരീകരിക്കുക.

പുതിയ കണക്ഷനിൽ എന്ത് പരിശോധിക്കണം

ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിച്ച്, മറ്റെന്തെങ്കിലും പരീക്ഷിക്കുന്നതിന് മുമ്പ് അനുവദിച്ച വിലാസം അതിന്റെ override-നോട് യോജിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. എന്നിട്ട് രണ്ടാമത്തെ ക്ലയന്റിൽ നിന്ന് പേര് പരിഹരിച്ച് പേരിലൂടെ സേവനത്തിലേക്ക് ബന്ധിപ്പിക്കുക, അത് DNS റെക്കോർഡും റൂട്ടും ഫയർവാളും ഒരുമിച്ച് പരീക്ഷിക്കുന്നു. സെർവർ വശത്ത് മറുപടി പാത സ്ഥിരീകരിക്കുക, കാരണം പേര് പരിഹരിക്കപ്പെട്ടിട്ടും സേവനം എത്താനാകാതെ നിൽക്കുന്നത് പേരിടലിന്റെയല്ല, റൂട്ടിംഗിന്റെയോ നയത്തിന്റെയോ പ്രശ്നമാണ്. override പട്ടിക സർട്ടിഫിക്കറ്റ് പട്ടികയ്ക്കൊപ്പം സൂക്ഷിക്കുക, രണ്ടും ഒരുമിച്ച് പരിശോധിക്കാൻ.

മറ്റൊരു പൊതുനാമത്തിൽ വീണ്ടും നൽകിയ സർട്ടിഫിക്കറ്റ് അതിന്റെ override-നോട് യോജിക്കുന്നത് നിർത്തി ക്ലയന്റിനെ ഡൈനാമിക് pool-ലേക്ക് തിരികെ കൊണ്ടുവരുന്നു. ഏതെങ്കിലും ഐഡന്റിറ്റി മാറ്റത്തിന് ശേഷം അത് പ്രതീക്ഷിക്കുക.