IPsec പ്രൊപ്പോസലിൽ എന്താണ് ഉള്ളത്? IKE, ESP ഫീൽഡുകൾ
ഒരു പ്രൊപ്പോസൽ ഒരു പൂർണ്ണ ഓഫർ ആണ്, അൽഗോരിതങ്ങളുടെ സഞ്ചിയല്ല. ഏത് ഫീൽഡുകൾ IKE-യുടേതും ഏത് ESP-യുടേതുമാണെന്നും എന്തുകൊണ്ട് ഒരു പൊരുത്തക്കേട് മുഴുവൻ സെറ്റും നിരസിക്കുന്നുവെന്നും കാണുക.
IKE ആരംഭിക്കുന്നു, ഇരുവശവും AES പ്രഖ്യാപിക്കുന്നു, എന്നിട്ടും ടണൽ NO_PROPOSAL_CHOSEN-നൊപ്പം പരാജയപ്പെടുന്നു. ലോഗ് പ്രൊപ്പോസലിന്റെ പേര് പറയുന്നു, പക്ഷേ പൊരുത്തപ്പെടാത്ത ഫീൽഡ് പറയുന്നില്ല. ഒരു പ്രൊപ്പോസൽ ഒരു പൂർണ്ണ ഓഫർ ആണ്, ഒരു പൊരുത്തമില്ലാത്ത ഫീൽഡ് ആ വരിയെ മാത്രമല്ല, മുഴുവൻ സംയോജനത്തെയും അസാധുവാക്കുന്നു. ഇതിനെ സ്വതന്ത്ര അൽഗോരിതം തിരഞ്ഞെടുപ്പുകളുടെ സഞ്ചിയായി വായിക്കുന്നതാണ് പൊരുത്തക്കേട് അദൃശ്യമായി തുടരുന്നതിന്റെ സാധാരണ കാരണം.
വെവ്വേറെ പ്രൊപ്പോസൽ പട്ടികകളുള്ള രണ്ട് ചർച്ചകൾ
IKEv2 രണ്ട് സുരക്ഷാ അസോസിയേഷനുകൾ നിർമ്മിക്കുന്നു. ആദ്യത്തേത് നിയന്ത്രണ കൈമാറ്റത്തെ തന്നെ സംരക്ഷിക്കുന്ന IKE SA ആണ്, രണ്ടാമത്തേത് ESP വഴി നിങ്ങളുടെ ട്രാഫിക് കൊണ്ടുപോകുന്ന CHILD SA ആണ്. ഓരോന്നിനും സ്വന്തം പ്രൊപ്പോസൽ പട്ടികയുണ്ട്, ഒരു പിയർ ഒന്ന് സ്വീകരിച്ച് മറ്റൊന്ന് നിരസിക്കാം.
ഈ വിഭജനം ഒരു സാധാരണ ആശയക്കുഴപ്പം വിശദീകരിക്കുന്നു: പ്രവർത്തിക്കുന്ന IKE SA നിയന്ത്രണ ചാനലിലെ അൽഗോരിതങ്ങൾ പൊരുത്തപ്പെട്ടു എന്ന് മാത്രം തെളിയിക്കുന്നു. CHILD പ്രൊപ്പോസൽ പരാജയപ്പെട്ടാൽ, ആദ്യ ഘട്ടം പൂർത്തിയായി ലോഗുകൾ മുകളിൽ ആരോഗ്യകരമായി കാണപ്പെട്ടാലും ടണൽ ഒരു പാക്കറ്റും കൊണ്ടുപോകുന്നില്ല.
ഓരോ പട്ടികയിലെയും ക്രമവും പ്രധാനമാണ്. പ്രതികരിക്കുന്ന കക്ഷി ആരംഭകന്റെ ക്രമീകരിച്ച ഓഫറുകളിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ വിശാലമായി പൊരുത്തപ്പെടുന്ന ഒരു എൻട്രി ഇടുങ്ങിയതിന് മുകളിലേക്ക് മാറ്റുന്നത് ഏത് സ്യൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുമെന്ന് മാറ്റുന്നു, ഒരു അൽഗോരിതം പേരും മാറ്റാതെ. ഡിഫോൾട്ടുകളെ ആശ്രയിക്കാതെ ആ ക്രമം കോൺഫിഗറേഷനിൽ പിൻ ചെയ്യുക. സ്ഥിരമായ ക്രമം സൈറ്റുകൾക്കിടയിലുള്ള ലോഗ് താരതമ്യത്തെയും അർത്ഥവത്താക്കുന്നു.
ഏത് ഫീൽഡുകൾ ഏത് പ്രൊപ്പോസലിന്റേതാണ്
ഫീൽഡ് സെറ്റ് ചെറുതാണ്, പക്ഷേ രണ്ട് ചർച്ചകളിലും ഒരുപോലെയല്ല. ഒരു നിരയിലെ ഫീൽഡ് മറ്റതിൽ ഇല്ലായിരിക്കാം, അതിനാൽ പട്ടിക വരി വരിയായി വായിക്കുക. വാക്യഘടന നടപ്പാക്കലിനനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു; strongSwan-ന്റെ പ്രൊപ്പോസൽ ഡോക്യുമെന്റേഷൻ ഒരു നിർദ്ദിഷ്ട റഫറൻസാണ്.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
എൻക്രിപ്ഷൻ ഫീൽഡ് സൈഫർ പേരും മിക്ക വാക്യഘടനകളിലും അതിന്റെ കീ നീളവും സൂചിപ്പിക്കുന്നു. സമഗ്രത ഫീൽഡ് സൈഫർടെക്സ്റ്റ് പ്രാമാണീകരിക്കാൻ ഉപയോഗിക്കുന്ന ഹാഷ് സൂചിപ്പിക്കുന്നു, PRF IKE SA-യ്ക്കുള്ള കീ മെറ്റീരിയൽ ഉത്പാദിപ്പിക്കുന്ന ഫംഗ്ഷൻ സൂചിപ്പിക്കുന്നു. DH ഗ്രൂപ്പ് പുതിയ പങ്കിട്ട രഹസ്യ മെറ്റീരിയൽ സ്ഥാപിക്കുന്നു, അതുകൊണ്ടാണ് അത് ഇരുവശത്തും പ്രത്യക്ഷപ്പെടുന്നത്, പക്ഷേ വ്യത്യസ്ത ലക്ഷ്യങ്ങൾക്കായി.
വിപുലീകൃത ക്രമ നമ്പറുകൾ ഡാറ്റാ പാതയിൽ മാത്രം ഉള്ളതാണ്. അവ ക്രമ ഇടം വിശാലമാക്കുന്നു, CHILD പ്രൊപ്പോസലിന്റെ ഭാഗമായി ചർച്ച ചെയ്യപ്പെടുന്നു, അതിനാൽ അവിടത്തെ പൊരുത്തക്കേട് CHILD ഓഫർ നിരസിക്കുന്നു, IKE SA തൊടാതെ അവശേഷിക്കുന്നു.
ഒരു പൂർണ്ണ ഓഫർ എങ്ങനെ തിരഞ്ഞെടുക്കപ്പെടുന്നു
ഓരോ പ്രൊപ്പോസലും ഒരു സെറ്റാണ്, പ്രതികരിക്കുന്ന കക്ഷി ഓരോ നിർബന്ധിത ഫീൽഡും സ്വീകാര്യമായ സെറ്റ് അന്വേഷിക്കുന്നു. രണ്ട് പട്ടികകളിലും AES-ഉം SHA-256-ഉം ഉണ്ടായിരിക്കാം, എന്നിട്ടും പൊരുത്തപ്പെടുന്ന എൻട്രി ഇല്ലായിരിക്കാം, കാരണം കീ നീളം, PRF അല്ലെങ്കിൽ DH ഗ്രൂപ്പ് വ്യത്യസ്തമാണ്. താരതമ്യം ഓരോ അൽഗോരിതത്തിനല്ല, ഓരോ പ്രൊപ്പോസലിനാണ് നടക്കുന്നത്.
ഒന്നും പൊരുത്തപ്പെടാത്തപ്പോൾ പ്രതികരിക്കുന്ന കക്ഷി പരാജയപ്പെട്ട SA തരത്തോടൊപ്പം NO_PROPOSAL_CHOSEN അയയ്ക്കുന്നു. കോൺഫിഗറേഷൻ എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് അറിയിപ്പ് ഏത് പ്രൊപ്പോസൽ പട്ടികയെ സംബന്ധിക്കുന്നുവെന്ന് വായിക്കുക; IKE പ്രൊപ്പോസൽ നിരസിക്കപ്പെട്ടപ്പോൾ ESP അൽഗോരിതം മാറ്റുന്നത് ഒരു ഡീബഗ് ചക്രം പാഴാക്കുന്നു.
പ്രൊഫൈൽ ക്രമീകരിക്കുമ്പോൾ തിരഞ്ഞെടുപ്പ് സ്വഭാവം അറിയുന്നത് ഉപകരിക്കും. ചില നടപ്പാക്കലുകൾ ആരംഭകന്റെ ക്രമം ഇഷ്ടപ്പെടുന്നു, മറ്റുള്ളവ പ്രാദേശിക നയപ്രകാരം പുനഃക്രമീകരിക്കുന്നു, അതിനാൽ രണ്ട് വിൽപ്പനക്കാർക്കിടയിൽ പ്രവർത്തിക്കുന്ന ഒരു സ്യൂട്ട് അപ്രത്യക്ഷമാകാം കണക്ഷൻ ഏത് വശം ആരംഭിക്കുന്നുവെന്ന് നിങ്ങൾ മറിച്ചിടുമ്പോൾ.
AEAD ഒരു ഫീൽഡ് ചേർക്കുന്നതിനുപകരം നീക്കം ചെയ്യുന്നു
AES-GCM-ഉം ChaCha20-Poly1305-ഉം ഒരു പ്രവർത്തനത്തിൽ പ്രാമാണീകരണവും എൻക്രിപ്ഷനും ചെയ്യുന്നു. ഇവയിലൊന്ന് ESP-യ്ക്കായി തിരഞ്ഞെടുക്കുമ്പോൾ സമഗ്രത അൽഗോരിതം വെവ്വേറെ ചർച്ച ചെയ്യുന്നില്ല, കാരണം AEAD ഘടന അതിനെ ഉൾക്കൊള്ളുന്നു. അതിനാൽ AES-GCM-നെ SHA-256-നൊപ്പം ചേർക്കുന്ന പ്രൊപ്പോസൽ ഏറ്റവും നല്ല സാഹചര്യത്തിൽ അനാവശ്യവും ഏറ്റവും മോശത്തിൽ നിരസിക്കപ്പെടുന്നതുമാണ്.
PRF IKE വശത്ത് ഇപ്പോഴും വെവ്വേറെയാണ്, കാരണം അത് പേലോഡുകൾ സംരക്ഷിക്കുന്നതിനുപകരം നിയന്ത്രണ ചാനലിനുള്ള കീകൾ ഉത്പാദിപ്പിക്കുന്നു. അതുകൊണ്ടാണ് IKE പ്രൊപ്പോസലിന് AEAD സൈഫർ PRF-നോടും DH ഗ്രൂപ്പിനോടും നിയമാനുസൃതമായി സംയോജിപ്പിക്കാനാകുന്നത്, അതേസമയം അനുബന്ധ ESP പ്രൊപ്പോസൽ AEAD സൈഫറും ഐച്ഛിക PFS ഗ്രൂപ്പും മാത്രം പട്ടികപ്പെടുത്തുന്നു.
കീ നീളം എൻക്രിപ്ഷൻ ടോക്കണിന്റെ ഭാഗമാണ്, അതിനാൽ AES-128-GCM-ഉം AES-256-GCM-ഉം വ്യത്യസ്ത ഓഫറുകളാണ്. 256-bit കീകൾ അനുമാനിച്ച ഒരു ഗൈഡിൽ നിന്ന് പകർത്തിയ പ്രൊഫൈൽ 128-bit-നായി ക്രമീകരിച്ച എൻഡ്പോയിന്റുമായി പൊരുത്തപ്പെടില്ല, രണ്ട് വരികളും AES-GCM എന്ന് പറഞ്ഞാലും. രണ്ട് പിയറുകൾക്ക് സൈഫർ കുടുംബത്തിൽ യോജിക്കാം, എന്നിട്ടും ഡാഷിന് ശേഷമുള്ള സംഖ്യ കാരണം പരസ്പരം നിരസിക്കാം.
കോൺഫിഗറേഷനല്ല, ഇൻസ്റ്റാൾ ചെയ്ത SA വായിക്കുക
ക്രമീകരിച്ച പ്രൊപ്പോസൽ പട്ടിക ഒരു ഓഫറാണ്; ഇൻസ്റ്റാൾ ചെയ്ത SA ഫലമാണ്. strongSwan-ലും Linux കെർണലിലും രണ്ട് കാഴ്ചകളും ലഭ്യമാണ്:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ഓരോ SA-യ്ക്കും ചർച്ച ചെയ്ത അൽഗോരിതങ്ങൾ പ്രിന്റ് ചെയ്യുന്നു, CHILD AEAD ഉപയോഗിക്കുന്നുണ്ടോ എന്നതും ഉൾപ്പെടെ. ip xfrm state കെർണൽ യഥാർത്ഥത്തിൽ എന്ത് ഇൻസ്റ്റാൾ ചെയ്തുവെന്ന് കാണിക്കുന്നു, കീ പുതുക്കൽ നിങ്ങൾ രേഖപ്പെടുത്തിയതിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു സ്യൂട്ടിലേക്ക് പിൻവാങ്ങിയിട്ടില്ലെന്ന് സ്ഥിരീകരിക്കുന്ന സ്ഥലം അവിടെയാണ്.
തിരുത്തലിന് ശേഷം ആ ഔട്ട്പുട്ട് കോൺഫിഗറേഷന് അരികിൽ സൂക്ഷിക്കുക. ക്ലയന്റ് അപ്ഡേറ്റ് അതിന്റെ ഡിഫോൾട്ടുകൾ മാറ്റുമ്പോൾ, രേഖപ്പെടുത്തിയ സ്യൂട്ട് താരതമ്യത്തിന് ഒരു അടിസ്ഥാനരേഖ നൽകുന്നു, താരതമ്യം അന്വേഷണം വീണ്ടും തുടങ്ങുന്നതിനുപകരം മാറിയ ഫീൽഡിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു.