Ping പ്രവർത്തിക്കുന്നു പക്ഷേ VPN വഴിയുള്ള SSH പരാജയപ്പെടുന്നു: ഏത് ഘട്ടം തകർന്നു?
ഒരു വിശദമായ ശ്രമം TCP ലഭ്യത, SSH ഗതാഗതം, ഹോസ്റ്റ് ഐഡന്റിറ്റി, ഉപയോക്തൃ ലോഗിൻ, സെഷൻ അനുമതി എന്നിവ വേർതിരിക്കുന്നു, അതിനാൽ ടണലിനെക്കുറിച്ച് ഊഹിക്കുന്നത് നിർത്താം.
Ping പ്രതികരണങ്ങളും നിരസിക്കപ്പെട്ട SSH ലോഗിനും ഒരേ സമയം ശരിയാകാം, ആ ജോടി ടണലിനെ കുറ്റപ്പെടുത്തുന്നില്ല. എക്കോ പ്രതികരണങ്ങളും പോർട്ട് 22-ലേക്കുള്ള TCP കണക്ഷനും വ്യത്യസ്ത സെലക്ടർമാർ, വ്യത്യസ്ത നയങ്ങൾ, പലപ്പോഴും വ്യത്യസ്ത ലക്ഷ്യങ്ങൾ എന്നിവയുള്ള വ്യത്യസ്ത പരീക്ഷണങ്ങളാണ്. ഒരു ബോധ്യപൂർവ്വ ശ്രമം രേഖപ്പെടുത്തുക, തുടർന്ന് അത് എത്തിയ അവസാന ഘട്ടം പേരിടുക. ആ ഒരു തെളിവ് ഡസൻ കണക്കിന് അനുമാനാധിഷ്ഠിത കോൺഫിഗറേഷൻ മാറ്റങ്ങൾക്ക് പകരമാകുന്നു.
ഒരു ശ്രമം രേഖപ്പെടുത്തുക, ഒരു സെഷൻ തട്ടിനോക്കലല്ല
ക്ലയന്റ് ഒരിക്കൽ വിശദമായ ഡയഗ്നോസ്റ്റിക്സ്, കണക്ഷൻ പങ്കിടൽ പ്രവർത്തനരഹിതമാക്കി, പരിമിതമായ കണക്ട് ടൈംഔട്ടോടെ പ്രവർത്തിപ്പിക്കുക. പങ്കിടൽ പ്രവർത്തനരഹിതമാക്കുന്നത് പ്രധാനമാണ്, കാരണം മുമ്പ് പ്രാമാണീകരിച്ച ഒരു മാസ്റ്റർ കണക്ഷൻ അല്ലെങ്കിൽ പുതിയ ശ്രമത്തിന് മറുപടി നൽകി നിങ്ങൾ പിന്തുടരുന്ന പരാജയം മറയ്ക്കും.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]
ലക്ഷ്യം, വിലാസ കുടുംബം, സമയ മുദ്ര, അവസാന രഹസ്യമല്ലാത്ത പിശക് എന്നിവ സൂക്ഷിക്കുക. IPv4 ഫ്ലാഗ് എന്നത് ഈ ശ്രമം അതേ പേരിലേക്കുള്ള IPv6 പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല എന്നും അർത്ഥമാക്കുന്നു, അതിനാൽ അതിൽ നിന്ന് സാമാന്യവൽക്കരിക്കരുത്. ശ്രമം എവിടെ നിന്ന് നടത്തി എന്ന് രേഖപ്പെടുത്തുക. VPN ഗേറ്റ്വേയിലെ പരിശോധന അതിന് പിന്നിലെ ലാപ്ടോപ്പിന്റെ അതേ വീക്ഷണകോണമല്ല, ഈ ടിക്കറ്റുകളിലെ മിക്ക വൈരുദ്ധ്യങ്ങളും രണ്ടും കലർത്തുന്നതിൽ നിന്നാണ് വരുന്നത്.
ഒന്നും രണ്ടും ഘട്ടം: SSH-ന് മുമ്പ് TCP
ആദ്യ അതിർത്തി സോക്കറ്റിന്റെ ലഭ്യതയാണ്: ഒരു വിലാസം, ഒരു പോർട്ട്, പാക്കറ്റ് യഥാർത്ഥത്തിൽ പിന്തുടരുന്ന ഒരു പാത. TCP കണക്ഷൻ ഒരിക്കലും പൂർത്തിയാകുന്നില്ലെങ്കിൽ, അതിന് മുകളിൽ ഇപ്പോഴും ഒന്നുമില്ല, ഹോസ്റ്റ് കീകളും അക്കൗണ്ടുകളും പ്രസക്തമല്ല.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'
റെക്കോർഡിനെ ക്ലയന്റ് ശ്രമവുമായി ബന്ധിപ്പിക്കുക. SYN പുറത്തുപോയി ഒന്നും തിരികെ വരുന്നില്ലെങ്കിൽ അത് ഫിൽട്ടറിംഗ്, സെലക്ടർമാർ അല്ലെങ്കിൽ ദൂരെ വശത്ത് കാണാത്ത ഒരു പാതയെ സൂചിപ്പിക്കുന്നു; റീസെറ്റോടെയുള്ള മറുപടി ഉപേക്ഷിക്കുന്നതിന് പകരം സജീവമായി നിരസിക്കുന്ന ഒന്നിനെ സൂചിപ്പിക്കുന്നു. രണ്ടാം അതിർത്തി SSH പ്രോട്ടോക്കോൾ കൈമാറ്റം തന്നെയാണ്. പൂർത്തിയായി പിന്നീട് നിലയ്ക്കുന്ന TCP കണക്ഷൻ ലഭ്യത കടന്ന് ചർച്ചകൾ, സെർവർ മറുപടി അല്ലെങ്കിൽ പാക്കറ്റ് കൈകാര്യം ചെയ്യലിൽ പ്രവേശിച്ചു. അത് മറ്റൊരു അന്വേഷണമാണ്, വലിപ്പവുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ ആദ്യമായി സാധ്യമാകുന്നത് അവിടെയാണ്.
മൂന്നാം ഘട്ടം: ആരുടെ കീ മറുപടി നൽകി
ഗതാഗതം ഉയർന്നാൽ ക്ലയന്റ് സെർവറിന്റെ ഹോസ്റ്റ് കീ പരിശോധിക്കുന്നു. ഇവിടെയുള്ള നിരസിക്കൽ ഐഡന്റിറ്റിയെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, ക്രിപ്റ്റോഗ്രഫിയെക്കുറിച്ചല്ല: എതിർകക്ഷി നിങ്ങളുടെ നയം സ്വീകരിക്കാത്ത ഒരു കീ അവതരിപ്പിച്ചു. അതിനെ നിർത്തൽ വ്യവസ്ഥയായി കാണുക, സംഭാഷണത്തിന് പുറത്ത്, കൺസോളിലൂടെയോ ഹോസ്റ്റ് വീണ്ടും നിർമ്മിച്ച ഓപ്പറേറ്ററിലൂടെയോ പരിശോധിക്കുക. മുന്നറിയിപ്പ് നീക്കാൻ ഓർമ്മിച്ച എൻട്രി ഇല്ലാതാക്കുന്നത് നിരസിക്കേണ്ട ഏക എളുപ്പവഴിയാണ്, കാരണം അത് അപ്രതീക്ഷിതമായി എന്തോ മറുപടി നൽകിയതിന്റെ തെളിവ് നശിപ്പിക്കുന്നു.
ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ വീണ്ടും നിർമ്മിച്ചതാണെങ്കിൽ, പുതിയ വിരലടയാളം സ്ഥിരീകരിച്ചതിന് ശേഷം മാത്രം പഴയ റെക്കോർഡ് നീക്കം ചെയ്യുക, തീയതിയും കാരണവും രേഖപ്പെടുത്തുക. അടുത്ത എൻജിനീയർക്ക് അതേ മുന്നറിയിപ്പ് ലഭിക്കും, അയാൾക്ക് ഈ സന്ദർഭം ആവശ്യമാണ്.
നാലും അഞ്ചും ഘട്ടം: അക്കൗണ്ട് vs അനുമതി
പ്രാമാണീകരണം നാലാം അതിർത്തിയാണ്. നിരസിക്കപ്പെട്ട ക്രെഡൻഷ്യലുകൾ അർത്ഥമാക്കുന്നത് സെർവർ ശ്രമം വിലയിരുത്തി നിരസിച്ചു എന്നാണ്; VPN പാസ്വേഡിന് പകരം അക്കൗണ്ട്, സെർവർ സ്വീകരിക്കുന്ന ക്രെഡൻഷ്യൽ തരം, സെർവറിന്റെ സ്വന്തം നയം എന്നിവ പരിശോധിക്കുക. അഞ്ചാം അതിർത്തി വിജയകരമായ ലോഗിനിന് ശേഷമുള്ള അനുമതിയാണ്. പ്രാമാണീകരിച്ച ഉപയോക്താവിന് പോലും ഷെൽ, കമാൻഡ്, സബ്സിസ്റ്റം അല്ലെങ്കിൽ ഫോർവേഡിംഗ് നിഷേധിക്കാം, ക്ലയന്റിന്റെ അവസാന വരി മാത്രം വായിക്കുന്നവർക്ക് ആ നിഷേധങ്ങൾ പരാജയങ്ങളായി തോന്നും.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
കുറച്ച് പാസ്വേഡ് ശ്രമങ്ങൾ പരാജയപ്പെട്ടാൽ നിർത്തുക. ആവർത്തിച്ചുള്ള ഊഹങ്ങൾ ലോക്കൗട്ടുകൾ ഉണ്ടാക്കുന്നു, അവ പിന്നീട് രണ്ടാമത്തെ, അബന്ധമായ തകരാറായി തോന്നും, യഥാർത്ഥ ടിക്കറ്റിനേക്കാൾ സമയം എടുക്കും.
റോൾബാക്കും നിങ്ങൾ സൂക്ഷിക്കുന്ന രേഖയും
ഒരു സമയത്ത് ഒരു കാര്യം മാറ്റുക, വീണ്ടും പരീക്ഷിക്കുന്നതിന് മുമ്പ് എന്ത് മാറ്റി എന്ന് എഴുതുക. മാറ്റം ശ്രമം മോശമാക്കുന്നുവെങ്കിൽ, മറ്റൊരു തിരുത്ത് മുകളിൽ കൂട്ടിവെക്കുന്നതിന് പകരം ഉടൻ തിരികെയാക്കുക. യഥാർത്ഥ ക്ലയന്റിൽ നിന്നും സന്ദർഭത്തിൽ നിന്നും യഥാർത്ഥ പ്രവർത്തനം ആവർത്തിക്കുക. മറ്റൊരു യന്ത്രത്തിൽ നിന്ന്, മറ്റൊരു വിലാസ കുടുംബത്തിൽ വിജയകരമായ ലോഗിൻ പുനർനിർമ്മാണമല്ല, തിരുത്ത് തെളിയിക്കുന്നതുമില്ല.
നിങ്ങൾ പങ്കിടുന്നത് ശുദ്ധീകരിക്കുക. വിശദമായ ക്ലയന്റ് ഔട്ട്പുട്ടിൽ ആന്തരിക നാമങ്ങൾ, അക്കൗണ്ട് ലേബലുകൾ, കീ പാതകൾ, പൊതു കീ ഐഡന്റിഫയറുകൾ എന്നിവ ഉണ്ടാകാം, അതിനാൽ അസംസ്കൃത ട്രെയ്സിന് പകരം ഘട്ടംതോറുമുള്ള നിഗമനം പ്രസിദ്ധീകരിക്കുക.