VPN ഇല്ലാതെ Git നിൽക്കുമോ? OpenSSH IPQoS ഉപയോഗിച്ച് പാക്കറ്റുകൾ അടയാളപ്പെടുത്തുന്നു

ഓഫീസിൽ നിന്നുള്ള ക്ലോൺ പ്രവർത്തിക്കുന്നു, ഫോണിന്റെ ഹോട്ട്സ്പോട്ടിലൂടെയുള്ള അതേ ക്ലോൺ പ്രവർത്തിക്കുന്നു, എന്നാൽ ഹോട്ടൽ നെറ്റ്വർക്കിൽ നിന്നുള്ള അതേ ക്ലോൺ VPN ഓൺ ചെയ്യുന്നതുവരെ തൂങ്ങിക്കിടക്കുന്നു. SSH ഹാൻഡ്ഷേക്ക് അവസാനിക്കുന്നു, ആദ്യ യഥാർത്ഥ കൈമാറ്റത്തിൽ സെഷൻ നിശബ്ദമാകുന്നു. ക്ലൈന്റ് കോൺഫിഗറേഷനിൽ ചേർക്കുന്ന ഒരു വരി git-ഉം ssh-ഉം ഒരുമിച്ച് സുഖപ്പെടുത്തുന്നു. ഒരു ക്ലൈന്റ് ക്രമീകരണം ഒരേസമയം പല ഉപകരണങ്ങളെ നന്നാക്കുമ്പോൾ, തകരാർ ക്ലൈന്റ് അയയ്ക്കുന്നതിലാണ്, അത് അയയ്ക്കുന്ന ലിങ്കിലല്ല.

രോഗലക്ഷണം പാതയുടെ വ്യത്യാസമായി വായിക്കുക

ഒരു പ്രശ്നം സുഖപ്പെടുത്തുന്ന ടണൽ അപൂർവ്വമേ അറ്റകുറ്റപ്പണിയാകൂ. അത് പാതയും വാഹകനും ഇടയിലുള്ള ഉപകരണങ്ങളും മാറ്റുന്നു, ലാപ്ടോപ്പ് അതേ പാക്കറ്റുകൾ തന്നെ ഉൽപ്പാദിപ്പിക്കുന്നു. ഒരു പാത ഹെഡർ തെറ്റായി കൈകാര്യം ചെയ്ത് മറ്റൊന്ന് അത് മാറ്റമില്ലാതെ കടത്തിവിട്ടാൽ, വ്യത്യാസം ഇടയിലുള്ള ഉപകരണത്തിന്റെ നയത്തിലാണ്, ക്ലൈന്റിലല്ല. ഇവിടെ ടണൽ സാക്ഷിയാണ്, പരിഹാരമല്ല.

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

ക്ലൈന്റ് ഓരോ SSH സോക്കറ്റിലും ഒരു QoS ബൈറ്റ് പതിക്കുന്നു

7.8 മുതൽ ഓരോ OpenSSH കണക്ഷനും IP ഹെഡറിൽ റൂട്ടറുകൾക്ക് ട്രാഫിക്കിന് മുൻഗണന നൽകാൻ ഉപയോഗിക്കാവുന്ന ഒരു മൂല്യം വഹിക്കുന്നു. ടെർമിനൽ സെഷനുകൾക്ക് ഒരു മൂല്യം, കൂട്ട പകർപ്പുകൾക്ക് മറ്റൊന്ന് — ടൈപ്പ് ചെയ്യുന്ന മനുഷ്യൻ ഫയൽ കൈമാറ്റത്തേക്കാൾ നല്ല പെരുമാറ്റത്തിന് അർഹനാണെന്ന സിദ്ധാന്തപ്രകാരം. മിക്ക നെറ്റ്വർക്കുകളും ഈ സൂചന പൂർണ്ണമായി അവഗണിക്കുന്നു, അതുകൊണ്ടാണ് വർഷങ്ങളോളം ഇത് ശ്രദ്ധയിൽപ്പെടാത്തത്. കുറച്ച് Wi-Fi ഡ്രൈവറുകളും മൊബൈൽ ഓപ്പറേറ്റർമാരും VPN കോൺസെൻട്രേറ്ററുകളും അതനുസരിച്ച് പ്രവർത്തിക്കുന്നു, അവയിൽ ചിലത് മോശമായി പ്രവർത്തിക്കുന്നു.

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

ആദ്യം ssh -V ഉപയോഗിച്ച് ക്ലൈന്റ് പതിപ്പ് സ്ഥിരീകരിക്കുക. 7.8 അല്ലെങ്കിൽ അതിനുമുകളിലുള്ള ഏതും ഈ സ്വഭാവം സ്വതവേ വഹിക്കുന്നു.

ഇതിനെ MTU-വിൽ നിന്നും DNS-ൽ നിന്നും വേർതിരിക്കുന്ന മൂന്ന് കമാൻഡുകൾ

ഏതെങ്കിലും കോൺഫിഗറേഷൻ ഫയൽ തിരുത്തുന്നതിന് മുൻപ് സമാനമായ രണ്ട് കാരണങ്ങൾ ഒഴിവാക്കണം. MTU തകരാർ ചെറിയ കൈമാറ്റങ്ങൾ കടത്തിവിട്ട് ആദ്യ വലിയ പാക്കറ്റിൽ മരവിക്കുന്നു, അതേസമയം പേരിന്റെ തകരാർ ഒരിക്കലും സെഷൻ സൃഷ്ടിക്കുന്നില്ല.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

ക്യാപ്ചർ സെർവറിലല്ല, ലാപ്ടോപ്പിൽ ചെയ്യുക, കാരണം മൂല്യം ഇടുന്നത് അയയ്ക്കുന്നവനാണ്, ഇരു ദിശകൾക്കും അത് മാറ്റാം. പ്രവർത്തിക്കുന്നതും പരാജയപ്പെടുന്നതുമായ പാതകൾ ഒരേ ക്യാപ്ചറിൽ താരതമ്യം ചെയ്യുക, ഊഹിക്കാതെ വ്യത്യാസം കാണാം.

ഒഴിവാക്കൽ ഒരു ഫയലിൽ വയ്ക്കുക, ഒരു സമയം ഒരു ഹോസ്റ്റ്

ഒഴിവാക്കൽ ബാധകമായ ഹോസ്റ്റിന് അടുത്തായിരിക്കണം, അത് എന്തിനാണെന്ന് പറയുന്ന ഒരു കുറിപ്പിനൊപ്പം.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

മൂല്യത്തേക്കാൾ പ്രധാനം പരിധിയാണ്. വൈൽഡ്കാർഡ് എൻട്രി എല്ലായിടത്തും സ്വഭാവം ഓഫാക്കുന്നു, നന്നായി പെരുമാറുന്ന നെറ്റ്വർക്കുകളിൽ സഹായകമായ സൂചന വലിച്ചെറിയുന്നു, എപ്പോൾ വന്നുവെന്ന് ആർക്കും പറയാനാകാത്തതാക്കുന്നു. ഓരോ ഹോസ്റ്റിനുമുള്ള എൻട്രി വായിക്കാവുന്നതും പഴയപടിയാക്കാവുന്നതും നെറ്റ്വർക്ക് നന്നായാൽ മായ്ക്കാൻ എളുപ്പവുമാണ്. വ്യക്തിപരമായ ഒഴിവാക്കലിന് ഉപയോക്തൃ ഫയലും, ഒരു മുഴുവൻ കൂട്ടത്തിനും അതേ ഒഴിവാക്കൽ വേണ്ടുമ്പോൾ മാനേജുചെയ്യുന്ന ഫയലും ഉപയോഗിക്കുക.

ഒഴിവാക്കൽ എന്തിനെ ഉൾക്കൊള്ളുന്നില്ല എന്ന് വ്യക്തമാക്കുക. ഇത് SSH-ന് ബാധകമാണ്, അതിനാൽ HTTPS റിമോട്ട്, പാക്കേജ് മിറർ, ബ്രൗസർ എന്നിവയെല്ലാം അതിന് പുറത്താണ്, അവയിലേതെങ്കിലും പരാജയപ്പെട്ടാൽ സ്വന്തം തെളിവ് വേണം. ബാസ്റ്റൺ വഴിയുള്ള ശൃംഖലയിൽ ഓരോ ചാട്ടവും ക്ലൈന്റ് കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നു, കുടുങ്ങുന്ന ചാട്ടമാണ് പരിധി നിർണ്ണയിക്കാൻ യോഗ്യമായത്.

നെറ്റ്വർക്ക് ഉടമയുമായി വൃത്തം അടയ്ക്കുക

കണ്ടെത്തൽ നാല് വസ്തുതകളായി കൈമാറുക: ക്ലൈന്റ് പതിപ്പ്, പരീക്ഷിച്ച പാത, ഉപയോഗിക്കുന്ന VPN ക്ലൈന്റ്, അടയാളം ഏത് ദിശ വഹിച്ചു. ഈ നാലും നെറ്റ്വർക്ക് ഉടമയ്ക്ക് പെരുമാറ്റം പുനരാവിഷ്കരിക്കാനും അത് മനഃപൂർവമാണോ എന്ന് തീരുമാനിക്കാനും മതി.

ഒഴിവാക്കൽ തൂങ്ങിനിൽപ്പ് സുഖപ്പെടുത്തുന്നില്ലെങ്കിൽ അത് നീക്കം ചെയ്യുക. പരാജയപ്പെട്ട പരീക്ഷണത്തിൽ നിന്ന് അതിജീവിക്കുന്ന പരിഹാരം ഐതിഹ്യമായി മാറുന്നു, അടുത്ത വ്യക്തി അത് ഒന്നും ചെയ്യുന്നില്ലെന്ന് തെളിയിക്കാൻ ഒരു മണിക്കൂർ ചെലവിടുന്നു. അത് തൂങ്ങിനിൽപ്പ് സുഖപ്പെടുത്തുന്നുവെങ്കിൽ, ആ പാത അതിലൂടെ കടക്കുന്ന മറ്റെല്ലാ ഉപകരണത്തിനും ഇപ്പോഴും തെറ്റാണ്, അറ്റകുറ്റപ്പണി ഇടയിലുള്ള ഉപകരണം പ്രവർത്തിപ്പിക്കുന്നവന്റേതാണ്.

ക്ലൈന്റിലെ മാറ്റം കാലാവധിയുള്ള താൽക്കാലിക പരിഹാരമാണ്. ആ തീയതി കുറിപ്പിൽ എഴുതുക.