Mac VPN ഒരിക്കൽ കണക്ട് ചെയ്ത ശേഷം സമയം തീരുന്നു: IKE ഡീമൺ വൃത്തിയാക്കുക

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

macOS-ൽ ആ എന്തോ സാധാരണയായി IKE ഡീമൺ ആണ്.

മാതൃക: ഒരു കണക്ഷൻ, പിന്നെ സമയം തീരൽ

ഓരോ ബൂട്ടിലും കൃത്യമായി ഒരിക്കൽ പ്രവർത്തിക്കുന്ന കണക്ഷൻ, വിച്ഛേദനത്തെ അതിജീവിക്കുന്നതും എന്നാൽ റീബൂട്ടിനെ അതിജീവിക്കാത്തതുമായ അവസ്ഥയെ സൂചിപ്പിക്കുന്നു. പ്രൊഫൈലുകൾ രണ്ടിനെയും അതിജീവിക്കുന്നു, അതിനാൽ പ്രൊഫൈൽ വേരിയബിൾ അല്ല. ക്രെഡൻഷ്യലുകളും രണ്ടിനെയും അതിജീവിക്കുന്നു, സർവർ അക്കൗണ്ട് ലോക്ക് ചെയ്യുന്നില്ലെങ്കിൽ. റീബൂട്ടിൽ മാറുന്നത് പ്രവർത്തിക്കുന്ന ഡീമണുകളുടെ കൂട്ടവും അവ പിടിച്ചിരിക്കുന്ന സോക്കറ്റുകളുമാണ്.

ഇത് ഒരു ലോഗ് തുറക്കുന്നതിന് മുമ്പുതന്നെ അന്വേഷണം ചുരുക്കുന്നു. ഏത് പ്രോസസ് IKE പോർട്ട് സ്വന്തമാക്കുന്നു, അത് താൻ എന്ത് ചെയ്യുന്നു എന്ന് കരുതുന്നു എന്നതാണ് ചോദ്യം.

രണ്ട് ഡീമൺ, ഒരു പോർട്ട്

സിസ്റ്റം പ്രവർത്തിപ്പിക്കുന്നു racoon ഒരു കണക്ഷൻ IKE പതിപ്പ് 1 സംസാരിക്കുമ്പോൾ. നിലവിലെ റിലീസുകൾ കൂടി കൊണ്ടുവരുന്നു iked IKEv2 ക്കും പുതിയ IPsec സ്റ്റാക്കിനും വേണ്ടിയുള്ളത്. രണ്ടും UDP 500 ഉം UDP 4500 ഉം ഉപയോഗിക്കാം, പാസ്വേഡ് പ്രോംപ്റ്റിൽ കണക്ഷൻ ശ്രമം റദ്ദാക്കപ്പെട്ടാലോ നെറ്റ്വർക്ക് മാറ്റം മൂലം തടസ്സപ്പെട്ടാലോ രണ്ടും പകുതി തുറന്ന സുരക്ഷാ അസോസിയേഷൻ നിലനിർത്താനും കഴിയും.

അങ്ങനെ സംഭവിക്കുമ്പോൾ, അടുത്ത ശ്രമം വൃത്തിയായി തുടങ്ങുന്നില്ല. പഴയ അസോസിയേഷൻ ഇപ്പോഴും പിയറിന്റെ അവസ്ഥ കൈവശപ്പെടുത്തിയിരിക്കെ അത് ചർച്ചയ്ക്ക് ശ്രമിക്കുന്നു, വ്യക്തമായ പിശകോടെ പരാജയപ്പെടുന്നതിന് പകരം കൈമാറ്റം തടഞ്ഞുനിൽക്കുന്നു. ഉപയോക്താവിന് കറങ്ങുന്ന സൂചകം കാണാം, പിന്നെ സമയം തീരുന്നു.

എന്തെങ്കിലും കൊല്ലുന്നതിന് മുമ്പ് ഉടമയെ കണ്ടെത്തുക, കാരണം ഉത്തരം ഏത് സേവനം പുനരാരംഭിക്കണം, അടുത്തതായി ഏത് ലോഗ് വായിക്കണം എന്ന് നിർണ്ണയിക്കുന്നു.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

ഔട്ട്പുട്ട് രണ്ട് വസ്തുതകളായി വായിക്കുക: ഏത് പ്രോസസ് പോർട്ട് പിടിച്ചിരിക്കുന്നു, ഒന്നിൽ കൂടുതൽ ഉണ്ടോ. ഒരേ സോക്കറ്റിനായി മത്സരിക്കുന്ന രണ്ട് IKE ഡീമണുകൾ അസ്ഥിരമായ സർവറിനെപ്പോലെ തോന്നുന്ന പല ഇടയ്ക്കിടെയുള്ള സ്വഭാവങ്ങളും വിശദീകരിക്കുന്നു.

പ്രോസസ് അല്ല, ജോലി പുനരാരംഭിക്കുക

പഴയ സിസ്റ്റങ്ങളിൽ പ്രോസസ് കൊന്ന് അടുത്ത കണക്ഷൻ അത് വീണ്ടും ആരംഭിക്കാൻ അനുവദിച്ചാൽ മതി. നിലവിലെ റിലീസുകളിൽ ഡീമൺ launchd നിയന്ത്രിക്കുന്നു, പ്രോസസിന് മാത്രം സിഗ്നൽ അയച്ചാൽ ജോലി പ്രവർത്തിക്കാത്തതും ആരംഭിക്കാൻ ഷെഡ്യൂൾ ചെയ്യാത്തതുമായ അവസ്ഥയിൽ അവശേഷിച്ചേക്കാം. പകരം ജോലി നിർത്തി ആരംഭിക്കുക.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

launchd-ന് ജോലിയുടെ രേഖയില്ലെങ്കിൽ, പേര് ഉപയോഗിച്ച് പ്രോസസ് കൊല്ലുന്നത് അടുത്ത ശ്രമത്തിൽ പുതിയ ചർച്ച നിർബന്ധമാക്കുന്നു. രണ്ട് സന്ദർഭങ്ങളിലും പരിശോധന ഒന്നുതന്നെ: വീണ്ടും കണക്ട് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ ഒരു പ്രോസസും പോർട്ട് പിടിച്ചിരിക്കരുത്. അതേ കമാൻഡ് ഉപയോഗിച്ച് അത് സ്ഥിരീകരിക്കുക lsof റീബൂട്ട് പ്രവർത്തിച്ചു എന്ന് അനുമാനിക്കുന്നതിന് പകരം.

പിന്നെ ഒരിക്കൽ കണക്ട് ചെയ്ത് ക്ലയന്റ് ലോഗ് ആദ്യം മുതൽ വായിക്കുക. ഘട്ടം 1 കടന്ന് പിന്നീട് ട്രാൻസ്മിറ്റ് പരാജയം റിപ്പോർട്ട് ചെയ്യുന്ന ചർച്ച പ്രാദേശിക സോക്കറ്റ് പ്രശ്നം ആവർത്തിക്കുന്നു; പിയർ നിരസിച്ച ചർച്ച തികച്ചും വ്യത്യസ്തമായ ടിക്കറ്റാണ്.

സർവർ തന്നെ നിരസിക്കുമ്പോൾ

എല്ലാ രണ്ടാം കണക്ഷനും പ്രാദേശികമായി പരാജയപ്പെടുന്നില്ല. വിച്ഛേദനത്തിന് ശേഷം ഒരു നിശ്ചിത വിൻഡോയിൽ സർവറിന് പുതിയ ലോഗിൻ നിരസിക്കാം, ക്ലയന്റിലെ സമയം തീരൽ കുടുങ്ങിയ ഡീമണിനെപ്പോലെ തന്നെ തോന്നും. വേർതിരിവ് വിലകുറഞ്ഞതാണ്: ഡീമൺ പുനരാരംഭിക്കുന്നത് സഹായിക്കുന്നില്ലെങ്കിലും മറ്റൊരു അക്കൗണ്ട് ഉടൻ കണക്ട് ചെയ്യുന്നുവെങ്കിൽ, വിൻഡോ സർവർ ഭാഗത്താണ്, Mac ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല.

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

ക്ലയന്റ് വീണ്ടും മാറ്റുന്നതിന് മുമ്പ് പിയറിന്റെ ലോഗ് വായിക്കുക. നിരസിക്കൽ, നയ പൊരുത്തക്കേട്, നിശബ്ദ ഒഴിവാക്കൽ എന്നിവ മൂന്ന് വ്യത്യസ്ത കാരണങ്ങളാണ്, Mac സ്ക്രീനിൽ അവയെല്ലാം “കണക്ട് ചെയ്യുന്നു” എന്ന് തോന്നുന്നു.

പഴയ ക്ലയന്റുകളും 64-ബിറ്റ് കേർണലും

പഴയ Cisco IPSec ക്ലയന്റ് 32-ബിറ്റ്, PowerPC സിസ്റ്റങ്ങൾക്കായി നിർമ്മിച്ച കേർണൽ എക്സ്റ്റൻഷൻ ലോഡ് ചെയ്യുന്നു. 64-ബിറ്റ് കേർണലിൽ ബൂട്ട് ചെയ്ത Mac-ൽ ആ എക്സ്റ്റൻഷൻ ലോഡ് ചെയ്യാനാകില്ല, ക്ലയന്റ് VPN സബ്സിസ്റ്റം ഒട്ടും എത്താത്തതിനാൽ പിശക് 51-നോടെ നേരത്തെ പരാജയപ്പെടുന്നു. തെറ്റായ ആർക്കിടെക്ചറുള്ള കേർണൽ എക്സ്റ്റൻഷൻ എത്ര ഡീമൺ പുനരാരംഭിച്ചാലും ശരിയാകില്ല.

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

• ഒരിക്കൽ പുനർനിർമ്മിക്കുക, പിന്നെ പ്രൊഫൈൽ തൊടുന്നതിന് മുമ്പ് ഏത് ഡീമൺ UDP 500 സ്വന്തമാക്കുന്നു എന്ന് പരിശോധിക്കുക.
• ഘട്ടം 1-ന് ശേഷമുള്ള ആദ്യ പരാജയം വായിക്കുക: ട്രാൻസ്മിറ്റ് പിശക് പ്രാദേശിക സോക്കറ്റിലേക്ക് സൂചിപ്പിക്കുന്നു.
• പ്രോസസ് മാത്രമല്ല, launchd ജോലി പുനരാരംഭിക്കുക, പോർട്ട് സ്വതന്ത്രമാണെന്ന് സ്ഥിരീകരിക്കുക.
• സർവർ ഭാഗത്തെ പുനർ-പ്രാമാണീകരണ വിൻഡോയെ ക്ലയന്റ് തകരാറിൽ നിന്ന് വേർതിരിക്കാൻ രണ്ടാം അക്കൗണ്ട് പരീക്ഷിക്കുക.
• ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് കേർണൽ ആർക്കിടെക്ചർ രേഖപ്പെടുത്തുക.

കൃത്യമായി ഒരിക്കൽ പ്രവർത്തിക്കുന്ന VPN, വിപരീതം തെളിയിക്കുന്നതുവരെ അവസ്ഥയുടെ പ്രശ്നമാണ്. ഡീമൺ വൃത്തിയാക്കുന്നത് റീബൂട്ടിനെക്കാൾ വേഗമേറിയതാണ്, റീബൂട്ട് എറിഞ്ഞുകളയുമായിരുന്ന ലോഗ് തെളിവുകൾ അത് സംരക്ഷിക്കുന്നു.