VPN ഓണായിരിക്കുമ്പോൾ രണ്ടാം സ്വകാര്യ പാതയിൽ SSH
ടണൽ വിലാസത്തിലേക്ക് ബന്ധിച്ച SSH ഡീമൺ പുതിയ സ്വകാര്യ ഇന്റർഫേസിൽ പ്രതികരിക്കില്ല. പഴയ സെഷൻ അടയ്ക്കുന്നതിന് മുമ്പ് ബൈൻഡിംഗ് ചേർത്ത് പുതിയ സെഷൻ പരിശോധിക്കുക.
ഒരു യന്ത്രം VPN വഴി മറ്റൊന്നിലെത്തുന്നു, ഇപ്പോൾ ആരോ അതേ ഷെൽ ദാതാവിന്റെ സ്വകാര്യ നെറ്റ്വർക്കിൽ ആഗ്രഹിക്കുന്നു. റൂട്ട് നിലവിലുണ്ട്, പിംഗ് വിജയിക്കുന്നു, എന്നിട്ടും SSH വിസമ്മതിക്കുന്നു. സാധാരണ കാരണം ഡീമൺ പുതിയ വിലാസത്തിൽ ഒരിക്കലും കേട്ടിട്ടില്ല എന്നതാണ്, അതിനാൽ ബന്ധിപ്പിക്കാൻ ഒന്നുമില്ല. ഇത് firewall പ്രശ്നമാകുന്നതിന് മുമ്പ് വിലാസ-ബൈൻഡിംഗ് പ്രശ്നമാണ്.
പുതിയ റൂട്ട് പുതിയ ശ്രോതാവിനെ സൃഷ്ടിക്കാത്തത് എന്തുകൊണ്ട്
കേൾക്കുന്ന സോക്കറ്റ് സ്വീകരിക്കുന്ന വിലാസങ്ങൾ പേരിടുന്ന ഒരു പ്രോസസ് സൃഷ്ടിക്കുന്നു. റൂട്ട് പാക്കറ്റുകൾക്ക് എവിടേക്ക് പോകണം എന്ന് മാത്രം പറയുന്നു; അത് ലക്ഷ്യസ്ഥാനത്ത് ശ്രോതാവിനെ സൃഷ്ടിക്കുന്നില്ല. sshd ഒരു ListenAddress ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യുമ്പോൾ, ഇന്റർഫേസ് പ്രവർത്തനക്ഷമമാണെങ്കിലും മറ്റേതെങ്കിലും ലോക്കൽ വിലാസത്തിലേക്കുള്ള കണക്ഷനുകൾ നിരസിക്കപ്പെടുന്നു. പോർട്ട് കൈവശം വയ്ക്കുന്ന സോക്കറ്റ് യൂണിറ്റിനും ഇത് ബാധകമാണ്, അതിനാൽ ആദ്യ പരിശോധന എപ്പോഴും യഥാർത്ഥത്തിൽ എന്താണ് കേൾക്കുന്നത് എന്നതാണ്.
രണ്ട് പാതകളെയും ഇന്റർഫേസ് പേരിന് പകരം ലക്ഷ്യ വിലാസം അനുസരിച്ച് താരതമ്യം ചെയ്യുക. ഒരു ക്ലൈന്റ് ഒരു വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുന്നു, ഏതെങ്കിലും firewall നിയമം പ്രധാനമാകുന്നതിന് മുമ്പ് ആ വിലാസം ബന്ധിച്ചിരിക്കണം.
വിലാസങ്ങളും ശ്രോതാക്കളും പട്ടികപ്പെടുത്തുക
എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ്, ഹോസ്റ്റിലെ വിലാസങ്ങളും ഇപ്പോൾ നിലവിലുള്ള സോക്കറ്റുകളും രേഖപ്പെടുത്തുക.
ip -br addr
ss -ltnp | grep ':22'വിലാസ പട്ടിക ഏത് സ്വകാര്യ വിലാസമാണ് യഥാർത്ഥമെന്നും ഏത് ഇന്റർഫേസിലാണെന്നും കാണിക്കുന്നു, സോക്കറ്റ് പട്ടിക അതിലേക്ക് എന്തെങ്കിലും ബന്ധിച്ചിട്ടുണ്ടോ എന്ന് കാണിക്കുന്നു. 0.0.0.0:22 എന്ന വിലാസത്തിൽ കേൾക്കുന്ന ശ്രോതാവ് ഇതിനകം എല്ലാ വിലാസങ്ങളും സ്വീകരിക്കുന്നു, അതിനാൽ പുതിയ ബൈൻഡിംഗ് ഒന്നും ചേർക്കുന്നില്ല. ഒരു നിർദ്ദിഷ്ട വിലാസത്തിൽ കേൾക്കുന്ന ശ്രോതാവ് നിരസിക്കലിന്റെ കാരണം ഉടൻ വിശദീകരിക്കുന്നു. പോർട്ട് ഡീമണിന് പകരം സോക്കറ്റ് യൂണിറ്റിന്റേതാണെങ്കിൽ, ഡീമൺ കോൺഫിഗറേഷൻ മുഴുവൻ കഥയല്ല.
ബൈൻഡിംഗ് ചേർത്ത് പഴയത് നിലനിർത്തുക
OpenSSH നിരവധി ListenAddress എൻട്രികൾ സ്വീകരിക്കുന്നു, അതിനാൽ സ്വകാര്യ പാത ചേർക്കുമ്പോൾ VPN പാത നിലനിൽക്കാം. റീലോഡ് ചെയ്യുന്നതിന് മുമ്പ് ഫയൽ പരിശോധിക്കുക.
sshd -t
systemctl reload sshdപരാജയപ്പെട്ട കോൺഫിഗറേഷൻ പരിശോധന പ്രവർത്തിക്കുന്ന ഡീമണിനെ തൊടാതെ വിടുന്നു, നിങ്ങൾ എഡിറ്റ് ചെയ്യുന്ന പാതയിലൂടെ ബന്ധിപ്പിച്ചിരിക്കുമ്പോൾ അതാണ് നിങ്ങൾക്ക് വേണ്ടത്. നിലവിലുള്ള എൻട്രി നിലനിർത്തി പുതിയ ലോക്കൽ വിലാസം ചേർത്ത്, നിലവിലെ സെഷൻ വിച്ഛേദിക്കാതെ സേവനം റീലോഡ് ചെയ്യുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. സോക്കറ്റ്-ആക്ടിവേറ്റഡ് ഇൻസ്റ്റാളേഷനുകളിൽ വിലാസം സോക്കറ്റ് യൂണിറ്റിലേക്ക് ചേർത്ത് ആ യൂണിറ്റ് റീലോഡ് ചെയ്യുക. തുടർന്ന് ശ്രോതാക്കളുടെ പട്ടിക വീണ്ടും വായിക്കുക, കാരണം ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത ബൈൻഡിംഗ് എന്നാൽ തെറ്റായ ഘടകമാണ് എഡിറ്റ് ചെയ്തത് എന്നാണ്.
പഴയ സെഷൻ അടയ്ക്കുന്നതിന് മുമ്പ് പുതിയ സെഷൻ പരിശോധിക്കുക
യഥാർത്ഥ സെഷൻ ഇപ്പോഴും തുറന്നിരിക്കെ പുതിയ വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുക, ഏത് വിലാസവും കീയും ഉപയോഗിച്ചുവെന്ന് കാണാൻ വിശദമായ ഔട്ട്പുട്ട് ഉപയോഗിക്കുക. പരിശോധന രണ്ടുതവണ വിജയിക്കുന്നതുവരെ യഥാർത്ഥ സെഷൻ തുറന്നിടുക.
ssh -v [email protected]ലക്ഷ്യ വിലാസത്തിനും അവതരിപ്പിച്ച ഹോസ്റ്റ് കീയ്ക്കുമുള്ള ഡീബഗ് വരികൾ വായിക്കുക. നെറ്റ്വർക്ക് സ്വകാര്യമാണെന്ന് വിവരിച്ചിരിക്കുന്നതിനാൽ അപരിചിതമായ കീ സ്വീകരിക്കുന്നതിന് പകരം, നിങ്ങൾ ഇതിനകം വിശ്വസിക്കുന്ന മൂല്യവുമായി ഹോസ്റ്റ് കീ ഫിംഗർപ്രിന്റ് സ്ഥിരീകരിക്കുക. പുതിയ ലക്ഷ്യത്തിന് സ്വന്തം known_hosts എൻട്രി ആവശ്യമാണ്, അത് പ്രതീക്ഷിക്കുന്നതാണ്. സ്വകാര്യ പാത പ്രവർത്തിച്ചതിന് ശേഷം മാത്രമേ പഴയ മാനേജ്മെന്റ് സെഷൻ അടയ്ക്കാവൂ.
SSH ഗതാഗതം സംരക്ഷിക്കുന്നു, പക്ഷേ ഒറ്റയ്ക്ക് അത് രണ്ട് നെറ്റ്വർക്കുകളെ തുല്യമാക്കുന്നില്ല. അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് സ്വകാര്യ ട്രാൻസിറ്റിന്റെ വിശ്വാസം ഡാറ്റയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക.