വരുന്ന IPsec പിയർ ഏതു പ്രൊഫൈലുമായും പൊരുത്തപ്പെടുന്നില്ലേ? നാല് ഫീൽഡുകൾ പരിശോധിക്കുക
ഫയലിലെ കണക്ഷൻ പേര് പ്രവർത്തിക്കുന്ന പ്രതികരിക്കുന്നയാൾ അത് തിരഞ്ഞെടുക്കുന്നതുവരെ ഒന്നും തെളിയിക്കുന്നില്ല. ലോഡ് ചെയ്ത നിർവചനം, അന്ത്യബിന്ദുക്കൾ, ഐഡന്റിറ്റികൾ, സെലക്ടറുകൾ എന്നിവ താരതമ്യം ചെയ്യുക.
നിങ്ങളുടെ പിയർ ടണൽ ഉയർന്നിട്ടുണ്ടെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, നിങ്ങളുടെ വശം ഒരു സുരക്ഷാ അസോസിയേഷനും കാണിക്കുന്നില്ല, കോൺഫിഗറേഷൻ ഫയലിൽ പൊരുത്തപ്പെടുന്ന കണക്ഷൻ പേര് വ്യക്തമായി ഉണ്ട്. ഈ മൂന്ന് പ്രസ്താവനകളും ഒരേസമയം ശരിയാകാം. വരുന്ന ചർച്ച പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനുമായി താരതമ്യം ചെയ്യുന്നു, പിയറിന്റെ വിലാസം, അത് അവതരിപ്പിക്കുന്ന ഐഡന്റിറ്റി, അത് നിർദ്ദേശിക്കുന്ന ട്രാഫിക് എന്നിവയുടെ അടിസ്ഥാനത്തിൽ. ഒരിക്കലും ലോഡ് ചെയ്യാത്ത ഡിസ്കിലെ ഫയൽ, പ്രതീക്ഷിച്ച മൂല്യവുമായി പൊരുത്തപ്പെടാത്ത ഐഡന്റിറ്റി, അല്ലെങ്കിൽ ഒരു പ്രിഫിക്സ് വ്യതിചലിച്ച സെലക്ടർ ജോടി — ഓരോന്നും നിശ്ശബ്ദത സൃഷ്ടിക്കുന്നു. പ്രതികരിക്കുന്നയാൾ പോകുന്ന ക്രമത്തിൽ നാല് ഫീൽഡ് ഗ്രൂപ്പുകളും സഞ്ചരിക്കുക.
ഫയലിൽ നിന്നല്ല, പാക്കറ്റിൽ നിന്ന് തുടങ്ങുക
പ്രതികരിക്കുന്നയാൾ ഒരു IKE അഭ്യർത്ഥന സ്വീകരിക്കുന്നു, ഈ പിയറിനെ സ്വീകരിക്കാൻ കഴിയുന്ന നിർവചനം തിരയുന്നു, തുടർന്ന് പ്രാമാണീകരണത്തിലും ട്രാഫിക് തിരഞ്ഞെടുപ്പിലും തുടരുന്നു. ആദ്യ ഘട്ടത്തിൽ ഒരു ലോഡ് ചെയ്ത നിർവചനവും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, ഉപയോഗപ്രദമായ പിശക് ഉപയോക്താവിനെ എത്തുന്നതിന് മുൻപേ ചർച്ച അവസാനിക്കുന്നു.
അതുകൊണ്ട് “കോൺഫിഗറേഷൻ ശരിയായി കാണുന്നു” എന്നത് തെളിവല്ല. ചോദ്യം, പ്രവർത്തിക്കുന്ന സേവനം എന്താണ് ലോഡ് ചെയ്തത്, ഈ ശ്രമത്തിന് ഏത് എൻട്രി തിരഞ്ഞെടുത്തു എന്നതാണ്. സ്റ്റാറ്റസ് ലിസ്റ്റ് അതിന് ഒരു കമാൻഡിൽ ഉത്തരം നൽകുന്നു, എഡിറ്റർ ബഫർ മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. ഫയൽ വീണ്ടും മാറ്റുന്നതിന് മുൻപ് ലിസ്റ്റ് പരിശോധിക്കുക.
ആദ്യ ഫീൽഡ് ഗ്രൂപ്പ്: യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത നിർവചനം
പ്രവർത്തിക്കുന്ന അവസ്ഥ ഡീമണിന്റെ ഉടമസ്ഥതയിലുള്ള ഉപകരണം ഉപയോഗിച്ച് പരിശോധിക്കുക: ലോഡ് ചെയ്ത കണക്ഷനുകൾ ലിസ്റ്റ് ചെയ്യുന്ന സ്റ്റാറ്റസ് കമാൻഡ്, എഡിറ്റർ ബഫർ അല്ല. പ്രതീക്ഷിക്കുന്ന എൻട്രി ഉണ്ടെന്നും, നിങ്ങൾ ഉദ്ദേശിക്കുന്ന സ്റ്റാർട്ടപ്പ് സ്വഭാവത്തിന് സജീവമാണെന്നും, നിങ്ങളുടെ അവസാന എഡിറ്റിന് ശേഷം ലോഡ് ചെയ്തുവെന്നും സ്ഥിരീകരിക്കുക. സേവ് ചെയ്ത് വീണ്ടും ലോഡ് ചെയ്യാത്ത ഫയലാണ് “ശരിയാക്കി, പക്ഷേ ഒന്നും മാറിയില്ല” എന്നതിന്റെ ഏറ്റവും സാധാരണ കാരണം.
സേവനം ഏത് ഫയലാണ് വായിക്കുന്നതെന്നും സ്ഥിരീകരിക്കുക. വിതരണങ്ങൾ വ്യത്യസ്തമാണ്, തെറ്റായ ഇൻക്ലൂഡിൽ എഴുതിയ കണക്ഷൻ നിരസിക്കുന്നതിന് പകരം നിശ്ശബ്ദമായി അവഗണിക്കുന്നു. സ്റ്റാറ്റസ് ലിസ്റ്റ് നിങ്ങളുടെ എൻട്രി ഒട്ടും കാണിക്കുന്നില്ലെങ്കിൽ, സിന്താക്സിന് മുൻപ് ഇൻക്ലൂഡ് പാതയെ സംശയിക്കുക.
രണ്ടാം ഫീൽഡ് ഗ്രൂപ്പ്: അന്ത്യബിന്ദുക്കൾ ഐഡന്റിറ്റികളല്ല
പിയർ ബന്ധിപ്പിക്കുന്ന വിലാസവും അത് പ്രാമാണീകരിക്കുന്ന ഐഡന്റിറ്റിയും വെവ്വേറെ ഫീൽഡുകളാണ്. ഹോസ്റ്റ്നാമം, വിശിഷ്ട നാമം, കീ ഐഡി, വിലാസം — കോൺഫിഗറേഷൻ അനുസരിച്ച് എല്ലാം IKE ഐഡന്റിറ്റിയാകാം, പൊതു വിലാസത്തോട് സാമ്യം വേണമെന്ന നിർബന്ധമില്ല.
അന്ത്യബിന്ദു പൊരുത്തത്തിൽ NAT ദൃശ്യവും ഉണ്ടാകാം: നെറ്റ്വർക്കിൽ കാണുന്ന വിലാസം പിയർ തനിക്കുണ്ടെന്ന് കരുതുന്ന വിലാസത്തിൽ നിന്ന് വ്യത്യസ്തമാകാം. libreswan ന്റെ കണക്ഷൻ മാതൃകയിൽ left ഉം right ഉം രണ്ട് പങ്കാളികളുടെ ലേബലുകളാണ്, സ്ഥിരമായ പ്രാദേശിക-ദൂര ക്രമമല്ല, അതിനാൽ പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ മറ്റൊരു സൈറ്റിൽ നിന്ന് പകർത്തി വിലാസങ്ങൾ മാറ്റുന്നത് വിശ്വസനീയമായ വിവർത്തനമല്ല.
ഇരു വശങ്ങളുടെയും പ്രതീക്ഷിത ഐഡന്റിറ്റിയും അത് സാധൂകരിക്കുന്ന ക്രെഡൻഷ്യലും എഴുതിവയ്ക്കുക. ആ രണ്ട് വരികൾ പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, എത്ര വിലാസ ക്രമീകരണവും പൊരുത്തം നൽകില്ല.
മൂന്നാം ഫീൽഡ് ഗ്രൂപ്പ്: സംരക്ഷിക്കപ്പെടുന്ന ട്രാഫിക്
സെലക്ടറുകൾ ആന്തരിക ഉറവിട, ലക്ഷ്യ ശ്രേണികളും അവയുടെ വിലാസ കുടുംബവും ഏതെങ്കിലും പ്രോട്ടോക്കോൾ അല്ലെങ്കിൽ പോർട്ട് നിയന്ത്രണവും വിവരിക്കുന്നു. ഒരു ഹോസ്റ്റ് വിലാസത്തിനുള്ള നിർദ്ദേശം മുഴുവൻ സബ്നെറ്റിനുള്ള അഭ്യർത്ഥനയല്ല, സബ്നെറ്റിനായി ക്രമീകരിച്ച പ്രതികരിക്കുന്നയാൾ അത് നിരസിച്ചേക്കാം അല്ലെങ്കിൽ ചുരുക്കിയേക്കാം.
രണ്ട് അറ്റങ്ങളും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, എന്തെങ്കിലും ബന്ധിപ്പിക്കാൻ ഓരോ സെലക്ടറും വിശാലമാക്കുന്നതിന് പകരം ഇരു കാഴ്ചപ്പാടുകളിൽ നിന്നും ഉദ്ദേശിച്ച പ്രവാഹം താരതമ്യം ചെയ്യുക. ഓരോ അഡ്മിനിസ്ട്രേറ്ററോടും താൻ സംരക്ഷിക്കുന്നതായി കരുതുന്ന പ്രവാഹം ചോദിക്കുക, എന്നിട്ട് രണ്ട് ഉത്തരങ്ങളും താരതമ്യം ചെയ്യുക. വ്യത്യാസം സാധാരണയായി ഒരു വശത്ത് ഹോസ്റ്റ് പ്രിഫിക്സും മറുവശത്ത് സബ്നെറ്റും ആണ്. ഇപ്പോൾ എല്ലാം സംരക്ഷിക്കുന്നതിനാൽ പൊരുത്തപ്പെടുന്ന ടണൽ മറ്റൊരു സുരക്ഷാ തീരുമാനമാണ്, ആരും അംഗീകരിക്കാത്തത്.
നാലാം ഫീൽഡ് ഗ്രൂപ്പ്: നിങ്ങൾ ഒരു നടപ്പാക്കൽ വായിക്കുന്നു
Libreswan, പഴയ Openswan, strongSwan എന്നിവയ്ക്ക് വ്യത്യസ്ത മാനേജ്മെന്റ് ഉപകരണങ്ങളും വ്യത്യസ്ത കോൺഫിഗറേഷൻ സിന്താക്സും വ്യത്യസ്ത പൊരുത്ത ക്രമവുമുണ്ട്. ഒന്നിൽ പ്രവർത്തിക്കുന്ന ഉദാഹരണം മറ്റൊന്നിന്റെ പ്രൊഫൈൽ തിരഞ്ഞെടുപ്പ് മുൻഗണനയെക്കുറിച്ചോ പിശക് രൂപീകരണത്തെക്കുറിച്ചോ കൃത്യമായി ഒന്നും പറയുന്നില്ല, അതിനാൽ ഈ ഹോസ്റ്റിലെ ഡീമണിന്റെ ഡോക്യുമെന്റേഷൻ ഉപയോഗിച്ച് പരിശോധിക്കുക.
ഒരു ശ്രമം ആദ്യം മുതൽ അവസാനം വരെ ബന്ധിപ്പിക്കുക: ആരംഭകന്റെ ഉറവിട വിലാസം, നൽകിയ ഐഡന്റിറ്റി, നിർദ്ദേശിച്ച സെലക്ടറുകൾ — പ്രതികരിക്കുന്നയാളുടെ തിരഞ്ഞെടുപ്പ് സന്ദേശത്തിനും അത് പേരിടുന്ന ലോഡ് ചെയ്ത എൻട്രിക്കും എതിരായി. പൂജ്യം എൻകാപ്സുലേഷൻ, ഡീകാപ്സുലേഷൻ കൗണ്ടറുകൾ നിരീക്ഷിച്ച അസോസിയേഷനുകൾ ആ പാക്കറ്റുകൾ വഹിച്ചിട്ടില്ല എന്ന് മാത്രം പറയുന്നു; അവ നിർദ്ദേശം നിരസിച്ച അന്ത്യബിന്ദുവിനെ പേരിടുന്നില്ല, ആ നിമിഷത്തിൽ പൊരുത്തപ്പെടുന്ന എൻട്രി ഉണ്ടായിരുന്നു എന്ന് തെളിയിക്കുന്നുമില്ല.
ഏകോപിത തിരുത്തലിന് ശേഷം തിരഞ്ഞെടുത്ത പ്രൊഫൈലും അസോസിയേഷനും സ്ഥിരീകരിക്കുക, എന്നിട്ട് യഥാർത്ഥത്തിൽ അനുവദിച്ച സേവനവും അതിന്റെ മറുപടി പാതയും പരീക്ഷിക്കുക. പ്രൊഫൈൽ പൊരുത്തം ചർച്ച സാധ്യമാക്കുന്നു, ചർച്ച അവസാന പ്രവേശന പരിശോധനയല്ല.