Windows, strongSwan സൈഫറുകൾ: ശരിയായ പാളി ചേർക്കുക

രണ്ടറ്റവും AES-128 എന്ന് പറയുന്നു, എന്നിട്ടും ടണൽ നിർമ്മിക്കാൻ വിസമ്മതിക്കുന്നു. CBC, GCM എന്നിവ യാദൃച്ഛികമായി ഒരേ കീ നീളം പങ്കിടുന്ന വ്യത്യസ്ത പരിവർത്തനങ്ങളാണ്, ഒന്ന് വാഗ്ദാനം ചെയ്യുന്ന ക്ലയന്റ് മറ്റൊന്ന് മാത്രം സ്വീകരിക്കുന്ന ഗേറ്റ്വേയെ തൃപ്തിപ്പെടുത്തുന്നില്ല. AES എന്ന വാക്ക് ഒരു കുടുംബത്തെ വിവരിക്കുന്നു, ഒരു കരാറിനെയല്ല.

രണ്ടാമതൊരു അച്ചുതണ്ടുമുണ്ട്, ആശയക്കുഴപ്പമുള്ള പിശകുകൾ സൃഷ്ടിക്കുന്നത് അതാണ്.

രണ്ട് പാളികൾ, രണ്ട് സ്വതന്ത്ര പട്ടികകൾ

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

പ്രായോഗിക ഫലം: പൂർണ്ണമായി സ്വീകാര്യമായ കീ കൈമാറ്റ നയവും പങ്കാളി സ്വീകരിക്കാത്ത ഡാറ്റാ ചാനൽ നയവും നിങ്ങൾക്ക് ഒരുമിച്ച് ഉണ്ടായിരിക്കാം. ഒരു പട്ടിക ചർച്ച നടത്തുന്നു; മറ്റൊന്ന് പാക്കറ്റുകൾ സംരക്ഷിക്കുന്നു. കോൺഫിഗറേഷൻ ഡയലോഗിൽ രണ്ടും എത്ര സമാനമായി കണ്ടാലും ആദ്യത്തേതിലെ മൂല്യം മാറ്റുന്നത് രണ്ടാമത്തേതിനെ ബാധിക്കുന്നില്ല.

ഗേറ്റ്വേയുമായി താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് പട്ടികകളും എഴുതി വയ്ക്കുക. ഓർമ്മയിൽ നിന്നുള്ള താരതമ്യം എന്നത് ഒരു ഫീൽഡ് രണ്ടുതവണ തിരുത്തുകയും മറ്റൊന്ന് ഒരിക്കലും തിരുത്താതിരിക്കുകയും ചെയ്യുന്ന രീതിയാണ്. പ്രൊഫൈലിന് അരികിൽ ഗേറ്റ്വേ കൺസോൾ തുറന്ന് വയ്ക്കുക.

നിർദ്ദേശങ്ങൾക്ക് അരികിൽ പിശക് വായിക്കുക

പരാജയപ്പെട്ട ഘട്ടം ഏത് പട്ടിക പരിശോധിക്കണമെന്ന് പറയുന്നു. പ്രാരംഭ കീ കൈമാറ്റത്തിനിടയിലെ നിരസിക്കൽ IKE നിർദ്ദേശത്തിന്റെ പ്രശ്നമാണ്, ഏതെങ്കിലും ചൈൽഡ് അസോസിയേഷൻ നിലവിൽ വരുന്നതിന് മുമ്പാണ് അത് സംഭവിക്കുന്നത്. സംരക്ഷിത ട്രാഫിക് അസോസിയേഷൻ ചർച്ച ചെയ്യുമ്പോഴുള്ള പരാജയം ESP നിർദ്ദേശത്തിന്റെ പ്രശ്നമാണ്, കീ കൈമാറ്റം ഇതിനകം വിജയിച്ചു. ക്ലയന്റിന്റെ പൊതുവായ നയ പൊരുത്ത സന്ദേശം രണ്ട് ഘട്ടങ്ങളിലൊന്നും പേര് പറയുന്നില്ല, അതിനാൽ ഗേറ്റ്വേയുടെ സ്വന്തം കാഴ്ചപ്പാടാണ് ഉപയോഗപ്രദം.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

ലഭിച്ച നിർദ്ദേശം, കോൺഫിഗർ ചെയ്ത നിർദ്ദേശം, തിരഞ്ഞെടുത്ത നിർദ്ദേശം എന്നിവ താരതമ്യം ചെയ്യുക ആ ഒരു ശ്രമത്തിന് വേണ്ടി. ഇവിടെ മൂന്ന് വ്യത്യസ്ത പട്ടികകൾ പ്രധാനമാണ്, യഥാർത്ഥത്തിൽ എന്താണ് ഉപയോഗിച്ചതെന്ന് അവസാനത്തേത് മാത്രം വിവരിക്കുന്നു. സംഗ്രഹിക്കുന്നതിന് പകരം ടിക്കറ്റിൽ അത് അക്ഷരാർത്ഥത്തിൽ ഉദ്ധരിക്കുക.

CBC, GCM എന്നിവ വേറിട്ട ബദലുകളായി നിലനിർത്തുക

ഏത് കുടുംബവും സ്വീകരിക്കാൻ ബോധപൂർവ്വം അനുവാദമുള്ള ഗേറ്റ്വേയ്ക്ക് ഒന്നല്ല, രണ്ട് നിർദ്ദേശങ്ങൾ വേണം. strongSwan-ൽ കോമ ബദലുകളെ വേർതിരിക്കുന്നു, ഹൈഫൻ ഒരു സ്യൂട്ടിന്റെ ഘടകങ്ങളെ ബന്ധിപ്പിക്കുന്നു. രണ്ട് കുടുംബങ്ങളെയും ഹൈഫനുകൾ കൊണ്ട് ചേർത്താൽ രണ്ട് സ്വീകാര്യ നിർദ്ദേശങ്ങൾക്ക് പകരം ഒരു അസാധ്യ നിർദ്ദേശമാകും.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

ആദ്യ ബദൽ പ്രാമാണീകൃത എൻക്രിപ്ഷൻ വഹിക്കുന്നു, ഇപ്പോഴും ഒരു സ്യൂഡോ-റാൻഡം ഫംഗ്ഷൻ പേര് പറയുന്നു, കാരണം സമഗ്രത സൈഫറിൽ നിന്ന് വന്നാലും കീ ഡെറിവേഷന് ഒന്ന് വേണം. രണ്ടാം ബദൽ വേറിട്ട സമഗ്രത അൽഗോരിതമുള്ള പരമ്പരാഗത എൻക്രിപ്ഷനാണ്. രണ്ടും ലോഡ് ചെയ്ത ക്രിപ്റ്റോ നിർവ്വഹണം എന്ത് പിന്തുണയ്ക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

ESP നിർദ്ദേശം പുനർനാമകരണം ചെയ്ത IKE നിർദ്ദേശമല്ല

സൈഫർ ടോക്കൺ രണ്ട് പട്ടികകളിലും ഒരുപോലെ കാണപ്പെടുന്നു, മറ്റൊന്നും കൈമാറ്റം ചെയ്യപ്പെടുന്നുമില്ല. ESP നിർദ്ദേശത്തിന് കീ കൈമാറ്റത്തിന്റെ സ്യൂഡോ-റാൻഡം ഫംഗ്ഷൻ ഇല്ല, അതിന്റെ സമഗ്രതയും മുന്നോട്ടുള്ള രഹസ്യതയും സംബന്ധിച്ച ആവശ്യകതകൾ IKE വരിയിൽ നിന്ന് പകർത്തുന്നതിന് പകരം മറുവശത്തെ Windows നയത്തിനെതിരെ വാദിക്കുന്നു. ഒരു പട്ടികയെ മറ്റൊന്നിലേക്ക് യാന്ത്രികമായി വിവർത്തനം ചെയ്താൽ സാധുത തെളിയിക്കപ്പെടുകയും ഒരിക്കലും ചർച്ച നടത്താതിരിക്കുകയും ചെയ്യുന്ന ഒന്ന് സൃഷ്ടിക്കപ്പെടും.

ഒരു ദിശ തിരഞ്ഞെടുത്ത് അതിൽ തുടരുക. ഒന്നുകിൽ ഗേറ്റ്വേ GCM മാത്രമുള്ള നയം സൂക്ഷിക്കുകയും ക്ലയന്റ് പൂർണ്ണമായ പൊരുത്തപ്പെടുന്ന നയം വിന്യസിക്കുകയും ചെയ്യുന്നു, അല്ലെങ്കിൽ ഗേറ്റ്വേ രണ്ട് കുടുംബങ്ങളെയും സ്വീകരിക്കുകയും ക്ലയന്റ് അതിന്റെ നിലവിലുള്ള സ്യൂട്ട് നിലനിർത്തുകയും ചെയ്യുന്നു. സുരക്ഷാ നയം വിലക്കുന്ന ഒരു ഫാൾബാക്ക് പ്രവർത്തനക്ഷമമാക്കുന്നത് എത്ര വേഗം പിശക് മാറ്റിയാലും പരിഹാരമല്ല.

രണ്ട് സ്യൂട്ടുകളും പരിശോധിക്കുക, തുടർന്ന് കീ പുതുക്കൽ

തിരഞ്ഞെടുത്ത കീ കൈമാറ്റ സ്യൂട്ടും തിരഞ്ഞെടുത്ത ട്രാഫിക് സ്യൂട്ടും വെവ്വേറെ സ്ഥിരീകരിക്കുക, കാരണം അവ വ്യത്യസ്ത പട്ടികകളിൽ നിന്ന് വരുന്നു, സ്വതന്ത്രമായി വിജയിക്കാനും കഴിയും. തുടർന്ന് ഒരു കീ പുതുക്കൽ സംഭവിക്കാൻ അനുവദിക്കുക, അതും സ്ഥിരീകരിക്കുക. പ്രവർത്തിക്കുന്ന ആദ്യ ഹാൻഡ്ഷേക്കും പരാജയപ്പെടുന്ന കീ പുതുക്കലും ഭാഗികമായി മാത്രം സ്വീകാര്യമായ ഒരു നിർദ്ദേശ കൂട്ടത്തെ വിവരിക്കുന്നു.

ആ തെളിവ് മാറ്റത്തിനൊപ്പം സൂക്ഷിക്കുക. ആവർത്തിക്കുന്ന കണക്ഷൻ വിച്ഛേദത്തിന് ആരെങ്കിലും ടൈമർ അല്ലെങ്കിൽ പ്ലാറ്റ്ഫോം തകരാർ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് അതിന്റേതായ പരാജയപ്പെട്ട കൈമാറ്റ രേഖ ആവശ്യമാണ്.