OpenVPN client-connect ഹുക്ക്: നിങ്ങളുടെ വിലാസം യഥാർത്ഥത്തിൽ എവിടെയാണ് പോകുന്നത്

client-connect സ്ക്രിപ്റ്റിൽ നിന്ന് വിലാസം തിരികെ നൽകുന്നത് ക്ലയന്റിന്റെ IP സജ്ജീകരിക്കേണ്ടതാണെന്ന് തോന്നുന്നു. പക്ഷേ അത് ചെയ്യുന്നില്ല: ഹുക്കിൽ നിന്ന് സെർവറിലേക്കുള്ള ഒരേയൊരു ചാനൽ ഒരു താൽക്കാലിക ഫയലാണ്, അതിന്റെ പാത സ്ക്രിപ്റ്റിന്റെ അവസാന ആർഗ്യുമെന്റായി വരുന്നു, വിലാസം അവിടെ ifconfig-push സിന്താക്സിൽ എഴുതണം. വിലാസം പ്രിന്റ് ചെയ്യുന്നതോ ഒന്നും എഴുതാതെ പൂജ്യത്തിൽ അവസാനിക്കുന്നതോ ആയ സ്ക്രിപ്റ്റ് പൂളിൽ നിന്നുള്ള വിലാസത്തോടെ ഒരു ബന്ധിപ്പിച്ച ക്ലയന്റ് സൃഷ്ടിക്കുന്നു, സെർവർ ലോഗ് തികച്ചും ആരോഗ്യകരമായി കാണപ്പെടുന്നു.

ആശയക്കുഴപ്പം ന്യായമാണ്, കാരണം മറ്റ് നിരവധി ഹുക്കുകൾ എക്സിറ്റ് കോഡുകളിലൂടെയോ പരിസ്ഥിതി വേരിയബിളുകളിലൂടെയോ യഥാർത്ഥത്തിൽ മറുപടി നൽകുന്നു. ഇതിന് സ്വന്തം കരാർ ഉണ്ട്, കരാർ ഒരു ഫയൽ നാമത്തിൽ തുടങ്ങുന്നു.

ഹുക്ക് ഒരു ഫയൽ എഴുതുന്നു, തിരികെ നൽകുന്ന മൂല്യമല്ല

പ്രഖ്യാപനം രണ്ട് വരികളാണ്: കോൾ അനുവദിക്കാൻ script-security 2, തുടർന്ന് client-connect /etc/openvpn/server/assign-address.sh. ഒരു ക്ലയന്റ് പ്രാമാണീകരിക്കുമ്പോൾ, സൃഷ്ടിച്ച ഫയൽ പാത അവസാന ആർഗ്യുമെന്റായി ചേർത്ത് സെർവർ ആ സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു, അത് $1 ആകുന്നത് പ്രഖ്യാപനം സ്വന്തം അധിക ആർഗ്യുമെന്റുകൾ നൽകാത്തപ്പോൾ മാത്രമാണ്. ആ ക്ലയന്റിൽ പ്രയോഗിക്കുന്ന എല്ലാം ആ ഫയലിൽ സാധാരണ നിർദ്ദേശങ്ങളായി, ഓരോ വരിയിലും ഒന്ന്, കോൺഫിഗറേഷനിൽ കാണുന്ന അതേ രീതിയിൽ എഴുതുന്നു. സ്വന്തം പാരാമീറ്ററുകൾ ചേർക്കുന്ന റാപ്പർ സ്ഥാനം മാറ്റുന്നു, ക്ലാസിക് ലക്ഷണം --verbose പോലെ തോന്നിക്കുന്ന പാതയിലേക്ക് എഴുതുന്ന സ്ക്രിപ്റ്റാണ്.

എക്സിറ്റ് നില കരാറിന്റെ മറ്റേ പകുതിയാണ്. പൂജ്യം എന്നാൽ സ്വീകരിച്ച് ഫയൽ വായിക്കുക; മറ്റെന്തും കണക്ഷൻ നിരസിക്കുന്നു, മാപ്പ് ചെയ്യാത്ത ഐഡന്റിറ്റി പൂളിലേക്ക് നിശബ്ദമായി മടങ്ങുന്നതിന് പകരം അങ്ങനെയാണ് നിരസിക്കപ്പെടുന്നത്. വിജയം തിരികെ നൽകുന്നതിന് മുമ്പ് പൂർണ്ണ നിർദ്ദേശം എഴുതുക, പകുതി എഴുതിയ ഫയൽ ഒരിക്കലും ക്ലയന്റിന്റെ കോൺഫിഗറേഷനാകാതിരിക്കാൻ.

രണ്ട് നിർദ്ദേശങ്ങൾ ശ്രദ്ധിക്കേണ്ടതാണ്, കാരണം അവ മറ്റെല്ലാമായി പ്രതിപ്രവർത്തിക്കുന്നു. ifconfig-push വിലാസം ഉറപ്പിക്കുന്നു, അയച്ച route ടണലിലൂടെ എന്ത് ലഭ്യമാണെന്ന് ക്ലയന്റിനോട് പറയുന്നു; ആദ്യത്തേത് തിരികെ നൽകി രണ്ടാമത്തേത് മറന്നാൽ വിലാസമുണ്ടെങ്കിലും പോകാൻ സ്ഥലമില്ലാത്ത ക്ലയന്റ് ലഭിക്കും. ഫയലിനുള്ളിലെ ക്രമം പ്രധാനമല്ല, പൂർണ്ണത പ്രധാനമാണ്. ഒരു പിയറിനും എത്താൻ കഴിയാത്ത പ്രിഫിക്സിന് റൂട്ട് അയക്കുന്ന ഹുക്ക് മറുവശത്ത് നിന്ന് കാണുന്ന അതേ തെറ്റാണ്.

ഇൻപുട്ടുകൾ പരിസ്ഥിതി വേരിയബിളുകളിലൂടെ വരുന്നു: common_name, trusted_ip, ifconfig_pool_remote_ip തുടങ്ങിയവ. ഇവയെല്ലാം സെർവറിന് പുറത്തുനിന്നുള്ള സ്ട്രിംഗുകളായി കാണുക, ഒരിക്കലും ഷെൽ ഭാഗങ്ങളായി അല്ല.

വിലാസ മാപ്പിംഗ് ഒരു നയമാണ്, ഗണിതമല്ല

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

നാമം നിയന്ത്രിക്കുന്നയാൾ വിലാസം നിയന്ത്രിക്കുന്നു, അതിനാൽ ഈ വിന്യാസത്തിൽ common_name യഥാർത്ഥത്തിൽ എന്തിനെ പ്രതിനിധീകരിക്കുന്നു എന്ന് തീരുമാനിക്കുക. username-as-common-name പ്രവർത്തനക്ഷമമാക്കിയാൽ ഐഡന്റിറ്റി ലോഗിൻ ആണ്, സർട്ടിഫിക്കറ്റ് സബ്ജക്റ്റല്ല. ആ മൂല്യം ഒരിക്കലും ഷെൽ മൂല്യനിർണ്ണയത്തിലേക്ക് നൽകരുത്, ക്ലയന്റിനെ ഒരിക്കലും ഒരു ഫയൽ പാതയെ സ്വാധീനിക്കാൻ അനുവദിക്കരുത്.

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

ifconfig-push എന്താണ് അർത്ഥമാക്കുന്നതെന്ന് ടോപ്പോളജി തീരുമാനിക്കുന്നു

10.77.0.0/24 ൽ topology subnet ഉള്ളപ്പോൾ, ifconfig-push 10.77.0.20 255.255.255.0 എന്നത് ഒരു വിലാസവും അതിന്റെ നെറ്റ്മാസ്കും ആണ്. topology net30 പ്രകാരം രണ്ടാമത്തെ ആർഗ്യുമെന്റ് മാസ്ക് അല്ല, പിയറിന്റെ വിലാസമാണ്, അതിനാൽ സബ്നെറ്റ് രൂപം net30 സെർവറിലേക്ക് പകർത്തിയാൽ ബന്ധിപ്പിക്കുന്നതും എന്നാൽ ട്രാഫിക് കടത്തിവിടാൻ കഴിയാത്തതുമായ ക്ലയന്റ് ലഭിക്കും. ടോപ്പോളജി ബോധപൂർവ്വം മാറ്റുക, ഉദാഹരണം സ്ഥിരതയുള്ളതായി തോന്നാൻ ഒരിക്കലും മാറ്റരുത്. ഇതിനകം net30 ൽ പ്രവർത്തിക്കുന്ന സെർവറിന് പഴയ അഡ്രസിംഗിൽ സജീവ ക്ലയന്റുകളുണ്ട്, അതിനാൽ മാറ്റം അറ്റകുറ്റപ്പണി വിൻഡോയുള്ള ഒരു കുടിയേറ്റമാണ്, ഒരു വരി തിരുത്തലല്ല.

സ്റ്റാറ്റിക് വിലാസങ്ങൾ ഡൈനാമിക് പൂളിന് പുറത്തും മറ്റെല്ലാ സ്റ്റാറ്റിക് അനുവദനങ്ങൾക്ക് പുറത്തും ആയിരിക്കണം, സാധാരണ client-config-dir ഫയലുകൾ നൽകുന്നവ ഉൾപ്പെടെ. രണ്ട് സംവിധാനങ്ങൾക്ക് വ്യത്യസ്ത ക്ലയന്റുകൾക്ക് ഒരേ വിലാസം ഉത്പാദിപ്പിക്കാൻ കഴിയുമെങ്കിൽ, അവയിലൊന്ന് ഒടുവിൽ അത് ചെയ്യും.

അതിൽ വിശ്വസിക്കുന്നതിന് മുമ്പ് നാല് കേസുകൾ പരീക്ഷിക്കുക

അതേ പരിശോധനകൾ മാപ്പ് ചെയ്ത ഐഡന്റിറ്റി, മാപ്പ് ചെയ്യാത്തത്, വീണ്ടും ബന്ധിപ്പിക്കൽ, അനുകരിച്ച രജിസ്ട്രി പരാജയം എന്നിവയ്ക്കെതിരെ പ്രവർത്തിപ്പിക്കുക. openvpn --config client.ovpn --verb 4 അനുവദിച്ച വിലാസം push മറുപടിയിൽ കാണിക്കുന്നു, സെർവറിൽ grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log യഥാർത്ഥത്തിൽ എന്താണ് അയച്ചതെന്ന് സ്ഥിരീകരിക്കുന്നു. മാപ്പ് ചെയ്യാത്ത ഐഡന്റിറ്റിക്ക് പ്രതീക്ഷിക്കുന്ന ഫലം നിരസിച്ച കണക്ഷനാണ്, പൂളിലെ വിലാസമല്ല.

തുടർന്ന് ഡീമൺ ആ താൽക്കാലിക ഫയലുകൾ എഴുതുന്ന ഡയറക്ടറി പരിശോധിക്കുക. സ്ക്രിപ്റ്റ് താഴ്ത്തിയ സേവന സന്ദർഭത്തിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ root എഴുതാൻ കഴിയുന്നതും എന്നാൽ ഡീമണിന് എഴുതാൻ കഴിയാത്തതുമായ പാത ഓരോ കണക്ഷനെയും ലോഗിൽ നിരവധി വരികൾ താഴെ കുഴിച്ചിട്ട അനുമതി പിശകിനൊപ്പം നിരസിക്കലാക്കി മാറ്റുന്നു.

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