strongSwan send_cert: IKE സർട്ടിഫിക്കറ്റ് എപ്പോൾ അയക്കുന്നു

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

send_cert യഥാർത്ഥത്തിൽ എന്താണ് നിയന്ത്രിക്കുന്നത്

സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ചുള്ള പ്രാമാണീകരണത്തിന് peer ന്റെ അന്തിമ-എന്റിറ്റി സർട്ടിഫിക്കറ്റ് IKE കൈമാറ്റം അല്ലെങ്കിൽ മുൻകൂർ തയ്യാറെടുപ്പ് വഴി മറുവശത്ത് എത്തണം. swanctl ൽ കണക്ഷൻ ക്രമീകരണം send_cert ഈ അന്തിമ പോയിന്റ് തന്റെ സർട്ടിഫിക്കറ്റ് പേലോഡ് ഉൾപ്പെടുത്തുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കുന്നു: ഒരിക്കലുമില്ല, എപ്പോഴും അല്ലെങ്കിൽ ifasked. സ്വതേയുള്ള ifasked അത് peer ൽ നിന്നുള്ള സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥനയ്ക്ക് മറുപടിയായി അയക്കുന്നു. സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നത് പ്രത്യേക ക്രമീകരണമാണ്, കാരണം മറുവശത്തോട് അതിന്റെ സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നത് സ്വന്തം വാഗ്ദാനം ചെയ്യുന്നതിന് തുല്യമല്ല.

പഴയ ipsec.conf വിന്യാസങ്ങൾ leftsendcert, rightsendcert ഉപയോഗിച്ചിരുന്നു, ആ പേരുകൾ പ്രാദേശിക, ദൂര പങ്കുകളുമായി യോജിക്കുന്നു, നേരിട്ട് swanctl മായി അല്ല.

കണക്ഷൻ മാറ്റുന്നതിന് മുൻപ് ഒരു ശ്രമം വായിക്കുക

ഒരു നിയന്ത്രിത ശ്രമത്തിൽ നിന്ന് രോഗനിർണ്ണയം ചെയ്യുക, സർട്ടിഫിക്കറ്റുകൾ ഉൾപ്പെട്ടിരിക്കുന്നു എന്ന പൊതുധാരണയിൽ നിന്നല്ല. നയവും സജീവ ബന്ധവും പരിശോധിക്കാം.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

കണക്ഷൻ പട്ടിക ക്രമീകരിച്ച send_cert മൂല്യം കാണിക്കുന്നു, SA പട്ടിക ഏത് കണക്ഷനുകൾ യഥാർത്ഥത്തിൽ ഉയർന്നു എന്ന് കാണിക്കുന്നു. ലോഗ് ചർച്ചയുടെ വിശദാംശങ്ങൾ ചേർക്കുന്നു: സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥന ലഭിച്ചോ, സർട്ടിഫിക്കറ്റ് പേലോഡ് പുറത്തേക്ക് പോയോ. പൊതുവായ പ്രാമാണീകരണ പരാജയം ഡെലിവറി പ്രശ്നം സൂചിപ്പിക്കുന്നില്ല, അതിനാൽ എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുൻപ് നിർദ്ദിഷ്ട കൈമാറ്റം തിരയുക. ശ്രമത്തിന്റെ സമയമുദ്ര രേഖപ്പെടുത്തുക, ലോഗ് വിൻഡോ മുഴുവൻ ഹാൻഡ്ഷേക്കും ഉൾക്കൊള്ളാൻ.

സ്വീകർത്താവിന്റെ വിശ്വാസം പ്രത്യേക തീരുമാനമാണ്

ഡെലിവറിയും വിശ്വാസവും വ്യത്യസ്ത ഗുണങ്ങളാണ്, ഒന്ന് ശരിയാക്കുന്നത് മറ്റൊന്ന് ശരിയാക്കുന്നില്ല. സ്വീകർത്താവിന് ഉദ്ദേശിച്ച വിശ്വാസ ആങ്കർ ഉണ്ടായിരിക്കണം, ഉപയോഗയോഗ്യമായ ശൃംഖല ലഭിക്കണം, പ്രതീക്ഷിച്ച peer ഐഡന്റിറ്റിയുമായി യോജിക്കണം. സ്വന്തം ഇടനില സർട്ടിഫിക്കറ്റ് ഇല്ലാതെ വരുന്ന അന്തിമ-എന്റിറ്റി സർട്ടിഫിക്കറ്റ് കർശന ശൃംഖല പരിശോധനയിൽ ഇപ്പോഴും പരാജയപ്പെടുന്നു. നേരെമറിച്ച്, ഒരു CA ഇൻസ്റ്റാൾ ചെയ്യുന്നത് peer തന്റെ സർട്ടിഫിക്കറ്റ് അയക്കാൻ ഒട്ടും നിർബന്ധിക്കുന്നില്ല.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

പരിശോധന ഏത് ഇഷ്യൂവർ സർട്ടിഫിക്കറ്റിൽ ഒപ്പിട്ടു, എപ്പോൾ കാലഹരണപ്പെടുന്നു എന്ന് കാണിക്കുന്നു, സ്വീകർത്താവിന്റെ ആങ്കർ അതിന് യോജിക്കണം. വിന്യാസത്തിന്റെ ഉടമസ്ഥതയിലുള്ള ഇഷ്യൂവർ CA വിശ്വസിക്കുക, ശൃംഖലയിലെ ഓരോ ഇടനില സർട്ടിഫിക്കറ്റിനെയുമല്ല, കാരണം ഓരോ ഇടനിലയെയും വേരിലേക്ക് ഉയർത്തുന്നത് വിശ്വാസം ഒരു peer നെക്കാൾ വളരെ ദൂരെ വ്യാപിപ്പിക്കുന്നു. ഐഡന്റിറ്റി സ്ഥിരീകരണം സജീവമായി നിർത്തുക, കാരണം സ്ഥിരീകരണം ഓഫ് ചെയ്താൽ മാത്രം വിജയിക്കുന്ന കണക്ഷൻ അറ്റകുറ്റപ്പണിയല്ല. ശൃംഖല അപൂർണ്ണമായിടത്ത്, തയ്യാറെടുപ്പ് ശരിയാക്കുക, അയക്കുന്നയാളുടെ നയമല്ല.

തെളിവോടെ മാത്രം അയക്കുന്നയാളെ മാറ്റുക

സർട്ടിഫിക്കറ്റ് ഒരിക്കലും അയച്ചിട്ടില്ലെന്നും സ്വീകർത്താവ് യഥാർത്ഥത്തിൽ അത് ആവശ്യപ്പെട്ടുവെന്നും ലോഗ് കാണിക്കുമ്പോൾ, send_cert always ആക്കി സജ്ജീകരിക്കുന്നത് ആ കണക്ഷന് ന്യായീകരിക്കാവുന്ന മാറ്റമാണ്. അത് swanctl കോൺഫിഗറേഷനിൽ പ്രയോഗിക്കുക, കണക്ഷനുകൾ വീണ്ടും ലോഡ് ചെയ്യുക, നിലവിലുള്ള SA വീണ്ടും ഉപയോഗിക്കുന്നതിന് പകരം പുതിയ സെഷൻ സ്ഥാപിക്കുക. സർട്ടിഫിക്കറ്റ് പേലോഡ് ഇപ്പോൾ പ്രത്യക്ഷപ്പെടുന്നുവെന്നും സ്വീകർത്താവ് അത് ഉദ്ദേശിച്ച ആങ്കറിന് എതിരായി സ്വീകരിക്കുന്നുവെന്നും സ്ഥിരീകരിക്കുക. ഒന്നും മാറുന്നില്ലെങ്കിൽ, പിഴവ് വിശ്വാസത്തിന്റെ ഭാഗത്തായിരുന്നു, അയക്കുന്നയാളുടെ ക്രമീകരണം കാരണമായിരുന്നില്ല.

നിരീക്ഷിച്ച കൈമാറ്റം, ആങ്കർ, അതിൽ നിന്നുള്ള സ്ഥിരീകരണം എന്നിവ മാറ്റ രേഖയിൽ എഴുതുക. ഈ പദങ്ങളിൽ വിവരിക്കാനാകാത്ത സർട്ടിഫിക്കറ്റ് അറ്റകുറ്റപ്പണി യാദൃച്ഛികമാണ്.