SSH2_MSG_KEX_ECDH_REPLY-ൽ SSH കുടുങ്ങുന്നു: എപ്പോഴും MTU അല്ല

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

മറുപടി യഥാർത്ഥത്തിൽ പ്രതീക്ഷിച്ചിരുന്നോ എന്ന് കാണാൻ ട്രെയ്സ് വായിക്കുക

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

അവസാന സന്ദർഭത്തിൽ, ക്ലയന്റിനെ തൊടുന്നതിന് മുമ്പ് സർവറിന്റെ പ്രാമാണീകരണ ലോഗ് വായിക്കുക. സർവർ ഒരിക്കലും അയച്ചിട്ടില്ലാത്ത ഒരു തീരുമാനം ക്ലയന്റിന് കാണാൻ കഴിയില്ല.

ചെറിയ മറുപടി എന്തുകൊണ്ട് ഇപ്പോഴും വളരെ വലുതായിരിക്കാം

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

വലിപ്പം അനുമാനിക്കാതെ നിർണ്ണയിക്കുക. ip link show tun0 ഉപയോഗിച്ച് ടണലിന്റെ MTU വായിക്കുക, തുടർന്ന് ഖണ്ഡിക്കരുതാത്ത പ്രോബുകൾ അയയ്ക്കുക: ping -4 -M do -s 1352 host, ചെറിയ പേലോഡുകളിൽ ആവർത്തിക്കുക. ഒരു നിർദ്ദിഷ്ട വലിപ്പത്തിൽ പരാജയത്തിൽ നിന്ന് വിജയത്തിലേക്കുള്ള മാറ്റം തെളിവാണ്; ഏകീകൃത പരാജയം ICMP ഫിൽട്ടർ ചെയ്യുന്നു എന്ന് സൂചിപ്പിക്കുന്നു, നിങ്ങളോട് ഒന്നും പറയുന്നില്ല.

താൽക്കാലിക കുറവ് സിദ്ധാന്തം വേഗത്തിൽ സ്ഥിരീകരിക്കുന്നു, സ്ഥിരമായ പതിപ്പ് പ്രൊഫൈലിലോ ടണൽ കൈമാറുന്ന റൂട്ടറിലെ MSS പരിധിയായോ വരുന്നു:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

വലിപ്പ പ്രശ്നത്തെ അനുകരിക്കുന്ന രണ്ട് കാരണങ്ങൾ

ക്ലയന്റിന് വായിക്കാൻ കഴിയാത്ത കീ ഫയൽ അതേ കാത്തിരിപ്പ് ഉണ്ടാക്കുന്നു, വിശദമായ ഔട്ട്പുട്ടിലും മുന്നറിയിപ്പില്ലാതെ. known_hosts-ലെ ഒരു പാറ്റേൺ ഇത് എളുപ്പമാക്കുന്നു: ഒരു അക്കൗണ്ടിന് മാത്രം വായിക്കാനാകുന്ന CA പൊതു കീയിലേക്ക് ചൂണ്ടുന്ന @cert-authority എൻട്രി. ഫയൽ ഉടമയായ അക്കൗണ്ട് കണക്റ്റ് ചെയ്യുന്നു, മറ്റെല്ലാ അക്കൗണ്ടുകളും കുടുങ്ങുന്നു. പരാജയം ഹോസ്റ്റിനെ അല്ല, ഉപയോക്താവിനെ പിന്തുടരുന്നുവെങ്കിൽ പാക്കറ്റ് വലിപ്പങ്ങൾക്ക് മുമ്പ് ഫയൽ മോഡുകൾ പരിശോധിക്കുക.

നവീകരണം ഇരു വശങ്ങളും മുമ്പ് പങ്കിട്ട അൽഗോരിതം നീക്കം ചെയ്തേക്കാം. സർവർ ഇപ്പോഴും വാഗ്ദാനം ചെയ്യുന്ന ഒരു രീതി രോഗനിർണ്ണയമായി പിൻ ചെയ്യുക: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. ഉടൻ വിജയിക്കുന്ന കണക്ഷൻ പാത ശരിയാണെന്ന് തെളിയിക്കുന്നു, തിരുത്തൽ ഇരു വശങ്ങളുടെയും ചർച്ചാ നയത്തിലാണ്.

എഴുതിവയ്ക്കാൻ യോഗ്യമായ മൂന്ന് വസ്തുതകൾ

ഏതെങ്കിലും മാറ്റത്തിന് മുമ്പും ശേഷവും ടണലിന്റെ MTU, വലിയ ഫയൽ പകർപ്പ് ആവർത്തിക്കാവുന്ന വലിപ്പത്തിൽ പരാജയപ്പെടുന്നുണ്ടോ, അതേ ടണലിലെ സർട്ടിഫിക്കറ്റില്ലാത്ത ഹോസ്റ്റും അതേപോലെ കുടുങ്ങുന്നുണ്ടോ എന്നും രേഖപ്പെടുത്തുക. ആ മൂന്ന് നിരീക്ഷണങ്ങൾ വലിപ്പത്തെ അനുമതികളിൽ നിന്നും ചർച്ചകളിൽ നിന്നും കമാൻഡുകളുടെ കൂമ്പാരത്തേക്കാൾ വേഗത്തിൽ വേർതിരിക്കുന്നു.

ഒരിക്കലും വലിപ്പവുമായി ബന്ധപ്പെടാത്ത ഒരു തകരാറിന് അടുത്ത വ്യക്തി MTU കുറയ്ക്കുന്നതും അവ തടയുന്നു.

ചിത്രം ഇപ്പോഴും വ്യക്തമല്ലെങ്കിൽ, അതേ ടണലിലെ രണ്ടാമത്തെ ക്ലയന്റിൽ നിന്ന് പരീക്ഷിക്കുക. കണക്റ്റ് ചെയ്യുന്ന ക്ലയന്റ് തകരാറിനെ പാതയിൽ നിന്ന് ആദ്യ യന്ത്രത്തിന്റെ കോൺഫിഗറേഷനിലേക്ക് മാറ്റുന്നു.