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

പിശക് ഒരു പ്രാദേശിക ബൈൻഡ് വിവരിക്കുന്നു, അതിനപ്പുറം ഒന്നുമില്ല. ഒരു ദാതാവ് പോർട്ട് തടയുന്നു, ക്ലയന്റ് തെറ്റായ പാസ്വേഡ് അയച്ചു, അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് ശൃംഖല തകർന്നു എന്നതിന് ഇത് തെളിവല്ല.

കൃത്യമായ ബൈൻഡ് പിശക് വായിക്കുക

ഈ കുടുംബത്തിലെ രണ്ട് പിശകുകൾ വ്യത്യസ്ത അർത്ഥങ്ങളാണ്, അവ കൂട്ടിക്കലർത്തുന്നത് നിങ്ങളെ തെറ്റായ പാളിയിലേക്ക് അയയ്ക്കുന്നു. «വിലാസം ഇതിനകം ഉപയോഗത്തിലാണ്» എന്നാൽ നിങ്ങൾ ആവശ്യപ്പെട്ട അന്ത്യബിന്ദു മറ്റൊരു സോക്കറ്റ് കൈവശം വച്ചിരിക്കുന്നു. «വിലാസം ലഭ്യമല്ല» എന്നാൽ ആവശ്യപ്പെട്ട വിലാസം ഈ ഹോസ്റ്റിൽ ഇതുവരെ നിലവിലില്ല, ഇത് തയ്യാറെടുപ്പിന്റെ പ്രശ്നമാണ്, പകർപ്പല്ല.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് പിശക് ടെക്സ്റ്റ് പകർത്തുക, അത് പേരിടുന്ന വിലാസവും പോർട്ടും ഉൾപ്പെടെ. ഒരു ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെടാൻ കാത്തിരിക്കുന്ന സേവനം രണ്ടാമത്തെ പിശക് ആവർത്തിച്ച് ലോഗ് ചെയ്യുകയും വിലാസം നിലവിൽ വന്നാൽ വിജയകരമായി ബൈൻഡ് ചെയ്യുകയും ചെയ്യും; ആദ്യത്തെ പിശക് ലോഗ് ചെയ്യുന്ന സേവനം പകർപ്പ് പരിഹരിക്കുന്നതുവരെ ഒരിക്കലും വിജയിക്കില്ല. ഏതാണ് കണ്ടതെന്ന് എഴുതിവയ്ക്കുന്നതിന് ഒന്നും ചെലവാകുന്നില്ല, വ്യർത്ഥമായ ഇന്റർഫേസ് അന്വേഷണം ലാഭിക്കുന്നു.

സോക്കറ്റ് കണക്കെടുക്കുക, പോർട്ടല്ല

പോർട്ട് നമ്പർ അപൂർണ്ണമായ കണക്കാണ്. അന്ത്യബിന്ദു ഒരു ട്രാൻസ്പോർട്ട്, ഒരു വിലാസ കുടുംബം, ഒരു പ്രാദേശിക വിലാസം, ഒരു പോർട്ട് എന്നിവയാണ്, എല്ലാം ഒരൊറ്റ നെറ്റ്വർക്ക് നെയിംസ്പേസിനുള്ളിൽ. ഒരേ നമ്പറിൽ UDP ശ്രോതാവും TCP ശ്രോതാവും വ്യത്യസ്ത സോക്കറ്റുകളാണ്, വ്യത്യസ്ത നെയിംസ്പേസുകളിൽ ഒരേ നമ്പറിലുള്ള രണ്ട് പ്രക്രിയകൾ ഒരിക്കലും കണ്ടുമുട്ടുന്നില്ല.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

ഏത് പ്രക്രിയയാണ് അതിന്റെ ഉടമ എന്ന് കണ്ടെത്തുക

സംഖ്യാപരമായ അന്ത്യബിന്ദുക്കളും പ്രക്രിയ വിവരങ്ങളും നിങ്ങളുടെ അനുമതികൾ അനുവദിക്കുമ്പോൾ ഉടമയെ തിരിച്ചറിയുന്നു, നിങ്ങൾക്ക് വേണ്ടത് ഉടമയാണ്, പ്രോഗ്രാം നാമമല്ല. രണ്ട് OpenVPN പ്രക്രിയകൾ വ്യത്യസ്ത പ്രൊഫൈലുകൾ പ്രവർത്തിപ്പിക്കാം, ശ്രോതാവിനെ കൈവശം വച്ചിരിക്കുന്നത് നിങ്ങൾ ഏറ്റവും കുറച്ച് പ്രതീക്ഷിക്കുന്നതായിരിക്കാം.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

നിങ്ങൾ കണ്ടെത്തിയത് സേവന മാനേജർ, ഒരു കണ്ടെയ്നർ റൺടൈം അല്ലെങ്കിൽ മുൻ പരീക്ഷയിൽ നിന്ന് അവശേഷിച്ച ഒരു ടെർമിനൽ പ്രക്രിയയുമായി താരതമ്യം ചെയ്യുക. പ്രക്രിയ വിശദാംശങ്ങളുടെ അഭാവം സോക്കറ്റിന് ഉടമയില്ല എന്നതിന് തെളിവല്ല; സാധാരണയായി അത് അന്വേഷണം മതിയായ അനുമതിയില്ലാതെ നടന്നു എന്നാണ് അർത്ഥം. അതുപോലെ, TCP മാത്രമുള്ള പട്ടിക UDP സംഘർഷം ഒഴിവാക്കുന്നില്ല, അതിനാൽ പിശകിൽ പേരിട്ട ട്രാൻസ്പോർട്ട് പരിശോധിക്കുക. പ്രക്രിയയുടെ പേര് മാത്രം ഏത് പ്രൊഫൈൽ ലോഡ് ചെയ്തുവെന്ന് ഒരിക്കലും പറയുന്നില്ല, കൂടാതെ പ്രൊഫൈൽ തന്നെയാണ് അന്ത്യബിന്ദു നിർണ്ണയിക്കുന്നത്.

ഒരു ഉടമ, അല്ലെങ്കിൽ രണ്ട് രൂപകൽപ്പന ചെയ്ത ഇൻസ്റ്റൻസുകൾ

വിന്യാസം ഒരു സെർവർ ഉദ്ദേശിക്കുന്നുവെങ്കിൽ, ഒരു ജീവിതചക്ര ഉടമ സൂക്ഷിക്കുക, അത് നിരീക്ഷിക്കാൻ രണ്ടാമത്തെ പകർപ്പ് ആരംഭിക്കുന്നതിന് പകരം ആ ഇൻസ്റ്റൻസിന്റെ ജേണലോ കോൺഫിഗർ ചെയ്ത ലോഗോ വായിക്കുക. നിയന്ത്രിത മുൻഗണനാ ഓട്ടം യഥാർത്ഥത്തിൽ ആവശ്യമാണെങ്കിൽ, നിയന്ത്രിത ഇൻസ്റ്റൻസ് ബോധപൂർവ്വം നിർത്തുക, അതിന് മുൻപ് അത് സേവനം നൽകുന്ന ക്ലയന്റുകളെ കണക്കിലെടുക്കുക.

രണ്ട് ഇൻസ്റ്റൻസുകൾ ഉദ്ദേശിക്കുന്നുവെങ്കിൽ, അവയ്ക്ക് വ്യത്യസ്ത ശ്രോതാക്കളും ബാക്കിയെല്ലാം വ്യത്യസ്തമായി നൽകുക: വിലാസ പൂളുകൾ, വെർച്വൽ ഇന്റർഫേസുകൾ, റൂട്ടിംഗ് നയം, കോൺഫിഗറേഷൻ ഉടമസ്ഥത. വ്യത്യസ്ത പോർട്ട് മാത്രം സോക്കറ്റല്ലാതെ മറ്റൊന്നും വേർതിരിക്കുന്നില്ല, രണ്ട് സെർവറുകളും ഒരേ പൂളിനും ഒരേ റൂട്ടുകൾക്കും വേണ്ടി തർക്കിക്കും.

മൂന്ന് ഷോർട്ട്കട്ടുകൾ പേരിടാൻ യോഗ്യമാണ്, കാരണം അവ ഈ പിശകിനെക്കുറിച്ചുള്ള എല്ലാ ചർച്ചയിലും പ്രത്യക്ഷപ്പെടുന്നു. കുറ്റവാളിയെപ്പോലെ തോന്നുന്ന ഏതെങ്കിലും PID കൊല്ലരുത്. സന്ദേശം നിശബ്ദമാക്കാൻ സോക്കറ്റ് പങ്കിടൽ പ്രവർത്തനക്ഷമമാക്കരുത്. സെർവർ പ്രൊഫൈൽ ക്ലയന്റ് ശൈലിയിലുള്ള ബന്ധിക്കാത്ത കോൺഫിഗറേഷനിലേക്ക് മാറ്റരുത്, കാരണം അത് ബൈൻഡ് പിശക് അപ്രത്യക്ഷമാക്കുന്നു; യഥാർത്ഥ സംഘർഷത്തേക്കാൾ രോഗനിർണ്ണയം ബുദ്ധിമുട്ടുള്ള രീതിയിൽ സെർവർ അപ്രാപ്യമാകും.

പോർട്ട് മാറ്റുന്നത് സാധുവായ ഉത്തരമാകുന്നത് പുതിയ ശ്രോതാവ് അംഗീകൃത രൂപകൽപ്പനയുടെ ഭാഗമാകുമ്പോൾ മാത്രമാണ്, അതിൽ ഫോർവേഡിംഗ് നിയമവും ക്ലയന്റ് അന്ത്യബിന്ദുവും ഉൾപ്പെടുന്നു. അവ അപ്ഡേറ്റ് ചെയ്തിട്ടില്ലെങ്കിൽ, ആർക്കും കണ്ടെത്താനാകാത്ത ഒരിടത്തേക്ക് സംഘർഷം മാറ്റിയിരിക്കുന്നു.

എല്ലാത്തിനും മുൻപ് ബൈൻഡ് പരിശോധിക്കുക

പരിമിതമായ തിരുത്തലിന് ശേഷം, ഉദ്ദേശിച്ച ഇൻസ്റ്റൻസ് സജീവമാണെന്നും അതിന്റെ ശ്രോതാവ് പ്രതീക്ഷിക്കുന്ന ട്രാൻസ്പോർട്ടിൽ പ്രത്യക്ഷപ്പെടുന്നുവെന്നും ഒരു ക്ലയന്റിന് കണക്റ്റ് ചെയ്യാമെന്നും സ്ഥിരീകരിക്കുക. വിജയകരമായ ബൈൻഡ് പ്രാദേശിക സോക്കറ്റ് ഘട്ടം മാത്രം പൂർത്തിയാക്കുന്നു; ടണൽ ഉയർന്നതിന് ശേഷമുള്ള പ്രാമാണീകരണത്തെക്കുറിച്ചോ ട്രാഫിക്കിനെക്കുറിച്ചോ ഇത് ഒന്നും സാക്ഷ്യപ്പെടുത്തുന്നില്ല.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

സോക്കറ്റ് ഉണ്ടെങ്കിൽ, ക്ലയന്റ് ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ, ബാക്കിയുള്ള പ്രശ്നം താഴെയാണ്, ബൈൻഡ് പിശക് ഇപ്പോൾ ചരിത്രമാണ്. കൃത്യമായ സന്ദേശം ആദ്യം വായിക്കുന്നതിന്റെ മുഴുവൻ അർത്ഥവും ആ വേർതിരിവാണ്: ഒരു പിശക്, ഒരു പാളി, ഒരു ഉടമ. അങ്ങനെ വായിക്കുക, അപ്പോൾ അടുത്ത ലക്ഷണം ഊഹത്തിൽ നിന്നല്ല, അറിയാവുന്ന അവസ്ഥയിൽ നിന്ന് ആരംഭിക്കും.

അനുബന്ധ ലേഖനങ്ങൾ