OpenVPN client-connect പരാജയം: disconnect-ൽ വൃത്തിയാക്കൽ ഉറപ്പുള്ളതാണോ?
നിരസിക്കപ്പെട്ട ക്ലയന്റ് ഫയർവാൾ നിയമമോ എഴുതിയ രേഖയോ തിരികെ നൽകുന്നില്ല. കോൾബാക്ക് കരാറിനെ നിങ്ങളുടെ hook സ്വയം ചെയ്യേണ്ട റോൾബാക്കുമായി താരതമ്യം ചെയ്യുക.
client-connect സ്ക്രിപ്റ്റ് പൂജ്യമല്ലാത്ത കോഡോടെ പുറത്തുപോകുമ്പോൾ, OpenVPN ക്ലയന്റിനെ നിരസിക്കുന്നു, ഒപ്പം ഓപ്പറേറ്റർമാർ സാധാരണയായി ബന്ധപ്പെട്ട client-disconnect സ്ക്രിപ്റ്റ് എല്ലാം ശരിയാക്കുമെന്ന് കരുതുന്നു. പലപ്പോഴും അത് ഒട്ടും പ്രവർത്തിക്കുന്നില്ല, കാരണം disconnect സംസ്കരണം connect ഘട്ടത്തിന് എന്ത് പൂർത്തിയാക്കാനായി എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. നിരസിക്കലും റോൾബാക്കും ഒരേ സംവിധാനമായി കാണുന്നതാണ് പരാജയപ്പെട്ട ലോഗിൻ ചോർന്ന ഫയർവാൾ നിയമമോ അനാഥ രേഖയോ ആക്കി മാറ്റുന്നത്. ഇവ രണ്ട് വ്യത്യസ്ത ബാധ്യതകളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് സ്വയമേവയുള്ളത്. സർവർ അവസ്ഥ വിട്ടുപോയി എന്ന് കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് hook-ന്റെ സ്വന്തം പുറത്തുകടക്കൽ പാത വായിക്കുക.
പൂജ്യമല്ലാത്ത പുറത്തുകടക്കൽ ക്ലയന്റിനെ നിരസിക്കുന്നു; അത് നിങ്ങളുടെ ജോലി തിരികെ നൽകുന്നില്ല
client-connect-ന്റെ പുറത്തുകടക്കൽ നില പ്രവേശന തീരുമാനമാണ്. പൂജ്യം എന്നാൽ പ്രവേശിപ്പിക്കുക, മറ്റേതെങ്കിലും മൂല്യം എന്നാൽ ഇൻസ്റ്റൻസ് പൂർണമായി സ്ഥാപിക്കുന്നതിന് മുൻപ് പൊളിച്ചുമാറ്റുക. ആ കരാറിൽ സ്ക്രിപ്റ്റ് പുറംലോകത്ത് ഇതിനകം എന്ത് ചെയ്തു എന്ന് പരിശോധിക്കുന്ന ഒന്നുമില്ല. സ്ക്രിപ്റ്റ് iptables നിയമം ചേർത്തിട്ടുണ്ടെങ്കിൽ, വരി എഴുതിയിട്ടുണ്ടെങ്കിൽ അല്ലെങ്കിൽ കൗണ്ടർ കൂട്ടിയിട്ടുണ്ടെങ്കിൽ, ആ മാറ്റങ്ങൾ നിരസിക്കലിന് ശേഷവും നിലനിൽക്കുന്നു.
അതേ അസമത്വം പ്ലഗിനുകൾക്കും ബാധകമാണ്, അവിടെ ഒരു ഇൻസ്റ്റൻസിനായി നിരവധി connect ഫംഗ്ഷനുകൾ പ്രവർത്തിക്കാം. പിന്നീടുള്ള പരാജയം മുൻകാല വിജയം പിന്നോട്ട് റദ്ദാക്കുന്നില്ല, മുൻ ഫംഗ്ഷന് സഹോദര ഫംഗ്ഷൻ പരാജയപ്പെട്ടു എന്ന് അറിയാനും വഴിയില്ല.
നിരസിക്കൽ സ്വയമേവയുള്ളതാണ്, വൃത്തിയാക്കൽ അല്ല
OpenVPN 2.6 സഹായി client-disconnect സംസ്കരണത്തെ മുൻ connect സംസ്കരണത്തിന്റെ വിജയവുമായി ബന്ധിപ്പിക്കുന്നു. രേഖപ്പെടുത്തിയ ഒരു അപവാദം കാസ്കേഡ് ശൃംഖലകളെ ഉൾക്കൊള്ളുന്നു: ഒരു connect ഘട്ടം ഇതിനകം വിജയം തിരികെ നൽകിയിട്ടുണ്ടെങ്കിൽ, പിന്നീടുള്ള connect ഘട്ടം പരാജയപ്പെട്ടാലും, ഇൻസ്റ്റൻസ് പൊളിക്കുമ്പോൾ ബന്ധപ്പെട്ട disconnect ഘട്ടങ്ങൾ എങ്കിലും പ്രവർത്തിക്കുന്നു. ആ അപവാദം ഇടുങ്ങിയതാണ്, എത്ര കോൾബാക്കുകൾ കോൺഫിഗർ ചെയ്തു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഒരു shell സ്ക്രിപ്റ്റ് പരീക്ഷിക്കുന്നത് ശൃംഖലയെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറയുന്നില്ല.
രൂപകൽപ്പന ചെയ്യുന്നതിന് മുൻപ് യഥാർത്ഥ കോൺഫിഗറേഷൻ മാപ്പ് ചെയ്യുക: ഏത് സ്ക്രിപ്റ്റ്, ഏത് പ്ലഗിൻ, ഏത് ക്രമത്തിൽ പ്രവർത്തിക്കുന്നു. താഴെയുള്ള പട്ടിക പകുതി പൂർത്തിയായ സജ്ജീകരണം എന്ത് വിട്ടേക്കുന്നു എന്ന് ലിസ്റ്റ് ചെയ്യുന്നു.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
ഓരോ വരിയും ക്ലയന്റിന് ഒരേ രീതിയിലും ഹോസ്റ്റിന് വ്യത്യസ്ത രീതിയിലും അവസാനിക്കുന്നു. അവയിൽ ഏതാണ് സംഭവിച്ചതെന്ന് ക്ലയന്റിന് പറയാനാവില്ല, അതിനാൽ hook പരാജയ നില തിരികെ നൽകുന്നതിന് മുൻപ് താൻ ചെയ്തത് തിരികെ എടുക്കണം.
പരാജയപ്പെട്ട സ്ക്രിപ്റ്റിനുള്ളിൽ നഷ്ടപരിഹാരം നൽകുക
പങ്കിട്ട അവസ്ഥ സ്പർശിക്കുന്നതിന് മുൻപ് കഴിയുന്നതെല്ലാം സാധൂകരിക്കുക: സർട്ടിഫിക്കറ്റ് ഫീൽഡുകൾ, വിലാസത്തിന്റെ ലഭ്യത, ക്ലയന്റ് ഉൾപ്പെടുന്ന ഗ്രൂപ്പ്. ഏറ്റവും വിലകുറഞ്ഞ നിരസിക്കൽ ഏതെങ്കിലും അനുവദനത്തിന് മുൻപ് സംഭവിക്കുന്നതാണ്. സജ്ജീകരണം നിരവധി ബാഹ്യ പ്രവർത്തനങ്ങളിലേക്ക് വ്യാപിക്കുമ്പോൾ, ഏതെല്ലാം പൂർത്തിയായി എന്ന് രേഖപ്പെടുത്തുക, പരാജയ നില തിരികെ നൽകുന്നതിന് മുൻപ് അവ വിപരീത ക്രമത്തിൽ തിരികെ എടുക്കുക.
ഒരു നിർദ്ദിഷ്ട സംഭവം: സ്ക്രിപ്റ്റ് ഓരോ ക്ലയന്റിനും ഫയർവാൾ എൻട്രി സൃഷ്ടിക്കുന്നു, പിന്നീട് അതിനെ വിവരിക്കുന്ന അവസ്ഥാ വരി എഴുതാൻ പരാജയപ്പെടുന്നു. പരാജയപ്പെട്ട ശാഖ ഇപ്പോൾ സൃഷ്ടിച്ച എൻട്രി നീക്കം ചെയ്ത് പിന്നീട് പൂജ്യമല്ലാത്ത കോഡോടെ പുറത്തുപോകണം. ഒരിക്കലും ഷെഡ്യൂൾ ചെയ്യപ്പെട്ടെന്ന് വരാത്ത disconnect ഇവന്റിനായി കാത്തിരിക്കുന്നതാണ് ഒരു നിയമം താൻ ഉദ്ദേശിച്ച സെഷനെക്കാൾ കൂടുതൽ ജീവിക്കുന്ന രീതി.
നഷ്ടപരിഹാരം ഇഡംപൊട്ടന്റും ഉടമസ്ഥതയുള്ളതുമാക്കുക
വൃത്തിയാക്കൽ രണ്ടുതവണ പ്രവർത്തിപ്പിക്കാൻ സുരക്ഷിതവും എന്ത് ഇല്ലാതാക്കാമെന്നതിൽ കൃത്യവുമായിരിക്കണം. മുൻ ശ്രമത്തിൽ നിന്നുള്ള വൈകിയ ഇവന്റ്, രണ്ടിനും പൊതുവായ ഒരു പേരോ പുനരുപയോഗിച്ച ടണൽ വിലാസമോ ഉള്ളതിനാൽ മാത്രം പുതിയ സെഷന്റെ അനുവദനം നീക്കം ചെയ്യരുത്. നിർദ്ദിഷ്ട ഹാൻഡിൽ അല്ലെങ്കിൽ ഓപ്പറേഷൻ ഐഡി റിസോഴ്സിനൊപ്പം രേഖപ്പെടുത്തുക, പേരനുസരിച്ചല്ല, ആ കീ ഉപയോഗിച്ച് ഇല്ലാതാക്കുക. ഡാറ്റാബേസ് ഇടപാടുകൾ ഡാറ്റാബേസിന്റെ സ്വന്തം മാറ്റങ്ങൾക്ക് മാത്രം സഹായിക്കുന്നു; ആ അതിർത്തിക്ക് പുറത്തുള്ള ഫയർവാൾ നിയമത്തിന് വ്യക്തമായ നഷ്ടപരിഹാര ഘട്ടം ആവശ്യമാണ്.
പ്രക്രിയ മാറ്റത്തിനും വൃത്തിയാക്കലിനും ഇടയിൽ മരിക്കാമെന്ന് കരുതുക, ഷെഡ്യൂൾ അനുസരിച്ച് ബാഹ്യ അവസ്ഥയെ സ്വീകരിച്ച ക്ലയന്റ് ലിസ്റ്റുമായി താരതമ്യം ചെയ്യുന്ന ഒരു പൊരുത്തക്കാരനെ ചേർക്കുക.
യഥാർത്ഥത്തിൽ വ്യത്യസ്തമായ മൂന്ന് പാതകൾ പരീക്ഷിക്കുക
മൂന്ന് സന്ദർഭങ്ങൾ പരിശീലിക്കുക: ഒന്നും അനുവദിക്കുന്നതിന് മുൻപുള്ള നിരസിക്കൽ, ഭാഗിക അനുവദനത്തിന് ശേഷമുള്ള നിരസിക്കൽ, പിന്നീട് അവസാനിക്കുന്ന സാധാരണ സ്വീകരിച്ച സെഷൻ. ആ മൂന്നും വ്യത്യസ്ത ലോഗ് വരികളും വ്യത്യസ്ത അവശിഷ്ടങ്ങളും ഉണ്ടാക്കുന്നു. ഓരോന്നിനും ശേഷം ബാഹ്യ അവസ്ഥ പരിശോധിക്കുക, ക്ലയന്റിന്റെ പരാജയ സന്ദേശം മാത്രമല്ല, കാരണം മൂന്നിൽ രണ്ടിൽ ക്ലയന്റിന്റെ പരാജയമാണ് പ്രതീക്ഷിത ഫലം.
hook-ന്റെ ഘട്ടം, പുറത്തുകടക്കൽ നില, എന്ത് അനുവദിക്കപ്പെട്ടു അല്ലെങ്കിൽ വിട്ടയച്ചു എന്നിവ ക്രെഡൻഷ്യലുകൾ ഒഴിവാക്കി ലോഗ് ചെയ്യുക. താൻ സൃഷ്ടിച്ച റിസോഴ്സ് പേരെടുത്ത് പറയുന്ന hook ലോഗ് ആണ് ചോർന്ന നിയമം ആറ് മാസത്തിന് ശേഷം കണ്ടെത്താനാകുന്നതാക്കുന്നത്.