WSL2-ലെ Git VPN-ൽ കുടുങ്ങുന്നു: ഇന്റർഫേസ് MTU അല്ലെങ്കിൽ പാത?

ക്ലോൺ പ്രമാണീകരിക്കുന്നു, ഒബ്ജക്റ്റുകളുടെ എണ്ണം പ്രത്യക്ഷപ്പെടുന്നു, പിന്നീട് മിനിറ്റുകളോളം ഒന്നും ചലിക്കുന്നില്ല. Windows VPN കണക്റ്റ് ചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്നു, ഹോസ്റ്റ്നെയിം പരിഹരിക്കപ്പെടുന്നു, അതേ മെഷീനിലെ ബ്രൗസർ അതേ റിപ്പോസിറ്ററി പേജ് ബുദ്ധിമുട്ടില്ലാതെ ലഭ്യമാക്കുന്നു. ഈ സംയോജനം ക്രെഡൻഷ്യലുകളെയല്ല, പാക്കറ്റ് വലിപ്പത്തെയാണ് സൂചിപ്പിക്കുന്നത്, കൂടാതെ വലിപ്പത്തിന്റെ ചോദ്യം രണ്ട് സ്ഥലങ്ങളിൽ ചോദിക്കണം കാരണം WSL2-ന് സ്വന്തം MTU ഉള്ള സ്വന്തം Linux ഇന്റർഫേസുണ്ട്. ഒരു സംഖ്യ പാതയുടെ Windows വശത്തിനും മറ്റൊന്ന് ഡിസ്ട്രിബ്യൂഷനും ഉള്ളതാണ്, VPN അഡാപ്റ്റർ മാത്രം വായിച്ചാൽ പാതയുടെ പകുതി പരിശോധിക്കാതെ അവശേഷിക്കുന്നു.

മൂന്ന് സൂചനകൾ വലിപ്പപ്രശ്നത്തെ മറ്റുള്ളവയിൽ നിന്ന് വേർതിരിക്കുന്നു

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

ഈ മൂന്നും ഒരുമിച്ച് പാക്കറ്റ്-വലിപ്പ സിദ്ധാന്തത്തെ ന്യായീകരിക്കുന്നു. DNS പരാജയം, കാലഹരണപ്പെട്ട ടോക്കൺ, നിരസിച്ച SSH കീ, CONNECT നിരസിക്കുന്ന പ്രോക്സി എന്നിവ ഓരോന്നും അവരുടേതായ പിശക് ഉണ്ടാക്കുന്നു, അവയൊന്നും വിജയത്തിന് ശേഷമുള്ള നിർത്തലിനോട് സദൃശ്യമല്ല. പരിശോധിക്കുമ്പോൾ അതേ റിപ്പോസിറ്ററിയും ഗതാഗതവും സമയവിന്യാസവും നിലനിർത്തുന്നതാണ് താരതമ്യത്തെ സത്യസന്ധമാക്കുന്നത്.

തീരുമാനിക്കുന്നതിന് മുമ്പ് രണ്ട് ഇന്റർഫേസുകളും താരതമ്യം ചെയ്യുക

ഒരേ സെഷനിൽ Windows കാഴ്ചയും Linux കാഴ്ചയും ശേഖരിക്കുക, ഏത് ഇന്റർഫേസ് അത് വഹിക്കുന്നു എന്ന് ഊഹിക്കുന്നതിന് പകരം റിപ്പോസിറ്ററിയുടെ വിലാസം പിടിക്കുക. താഴെയുള്ള കമാൻഡ് ആദ്യം ലക്ഷ്യസ്ഥാനം പരിഹരിക്കുന്നു, അതിനാൽ പാത അന്വേഷണം ക്ലോൺ യഥാർത്ഥത്തിൽ ബന്ധപ്പെടുന്ന സെർവറിനെ വിവരിക്കുന്നു, അത് ബ്രൗസർ കാണിച്ച പേരിൽ നിന്ന് വ്യത്യസ്തമായിരിക്കാം. രണ്ട് പകുതികളും പരസ്പരം അടുത്ത് പ്രവർത്തിപ്പിക്കുക, കാരണം VPN ശ്രമങ്ങൾക്കിടയിൽ ഇന്റർഫേസ് മെട്രിക്കുകൾ മാറ്റാം.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Windows ഷെല്ലിലേക്ക് ഔട്ട്പുട്ട് ഒട്ടിക്കുന്നതിന് പകരം Linux പകുതി ഡിസ്ട്രിബ്യൂഷനുള്ളിൽ പ്രവർത്തിപ്പിക്കുക, കാരണം ഇന്റർഫേസ് നാമങ്ങളും പാത തിരഞ്ഞെടുപ്പും അവിടെ മാത്രമേ അർത്ഥവത്താകൂ. Windows ഷെല്ലിൽ നിന്ന് ഒട്ടിച്ച ഫലം തെറ്റായ സംഖ്യകൾ വലിയ ആത്മവിശ്വാസത്തോടെ റിപ്പോർട്ട് ചെയ്യുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഓരോ വശത്തുനിന്നും ഉപകരണം, തിരഞ്ഞെടുത്ത പാത, MTU എന്നിവ രേഖപ്പെടുത്തുക.

സംഖ്യ ചെറുതായിരിക്കണമോ എന്ന് തീരുമാനിക്കുക

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

തെളിവുകൾ അതിനെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, Linux ഇന്റർഫേസിലെ താൽക്കാലിക മാറ്റമാണ് ഏറ്റവും വിലകുറഞ്ഞ പരിശോധന. ഉപയോഗയോഗ്യമായ പാത വലിപ്പത്തിൽ കുറഞ്ഞ ഒരു മൂല്യം തിരഞ്ഞെടുത്ത്, മുമ്പത്തേത് രേഖപ്പെടുത്തി, താരതമ്യത്തിന് അർത്ഥമുണ്ടാകാൻ ബാക്കിയെല്ലാം സ്ഥിരമായി നിർത്തുക. ചെറിയ മൂല്യത്തിൽ കൈമാറ്റം പൂർത്തിയായാൽ, നിങ്ങൾക്ക് യാദൃച്ഛികതയല്ല, രോഗനിർണയമുണ്ട്.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

ക്രമീകരണം എവിടെ ജീവിക്കണം എന്ന് തീരുമാനിക്കുക

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

സ്റ്റാർട്ട് ഹുക്ക് ഉണ്ടോ എന്നത് ഉപയോഗത്തിലുള്ള Windows, WSL പതിപ്പുകളെയും ക്രമീകരിച്ച നെറ്റ്വർക്കിംഗ് മോഡിനെയും ആശ്രയിച്ചിരിക്കുന്നു. Windows നെറ്റ്വർക്ക് പ്രതിബിംബിക്കുന്നത് VPN ഡിസ്ട്രിബ്യൂഷനുമായി ഇടപെടുന്ന രീതിയെ MTU ക്രമീകരണത്തേക്കാൾ പ്രധാനമായ രീതികളിൽ മാറ്റാം, അതിനാൽ അതിനുള്ള പകരവഴി രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് മോഡ് തിരിച്ചറിയുക. ഒരു ഓപ്പറേറ്റർക്കോ ഒരു VPN പ്രൊഫൈലിനോ അനുയോജ്യമായ മൂല്യം അടുത്തതിനുള്ള സ്ഥിരസ്ഥിതിയല്ല.

ഒഴിവാക്കേണ്ടത് പ്രലോഭിപ്പിക്കുന്ന സ്ഥാനമാണ്: ഓരോ ഇന്ററാക്ടീവ് ഷെല്ലിന്റെയും സ്റ്റാർട്ടപ്പ് ഫയലിൽ ഒരു പ്രത്യേകാവകാശ നെറ്റ്വർക്ക് കമാൻഡ്, അല്ലെങ്കിൽ ഒരു സ്ക്രിപ്റ്റിന് ഒരു വരി പ്രവർത്തിപ്പിക്കാൻ മുഴുവൻ ip ബൈനറിക്കും പാസ്വേഡില്ലാത്ത sudo. രണ്ടും രോഗനിർണയത്തെ സ്ഥിരമായ വെളിപ്പെടുത്തലാക്കി മാറ്റുകയും യഥാർത്ഥ പ്രശ്നം പിന്നീട് കാണാൻ ബുദ്ധിമുട്ടാക്കുകയും ചെയ്യുന്നു.

ശുദ്ധമായ തുടക്കത്തിന് ശേഷം പരിശോധിക്കുക, പിന്നീട് പഴയപടിയാക്കുക

ഡിസ്ട്രിബ്യൂഷൻ പുനരാരംഭിക്കുന്നതുവരെ മാത്രം നിലനിൽക്കുന്ന മാറ്റം പരിഹാരമല്ല. ഡിസ്ട്രിബ്യൂഷൻ പുനരാരംഭിച്ച്, VPN വീണ്ടും ബന്ധിപ്പിച്ച്, ping അല്ലെങ്കിൽ ചെറിയ HTTP അഭ്യർത്ഥന പോലുള്ള പകരമല്ല, യഥാർത്ഥ Git പ്രവർത്തനം ആവർത്തിക്കുക. തുടർന്ന് പുതിയ സെഷനിൽ ഇന്റർഫേസ് ഉദ്ദേശിച്ച മൂല്യം വഹിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

രേഖപ്പെടുത്തിയ യഥാർത്ഥ മൂല്യം മാറ്റത്തിനൊപ്പം സൂക്ഷിക്കുക, പരീക്ഷണം ശുദ്ധമായി പിൻവലിക്കാൻ, ഏത് വിലാസ കുടുംബമാണ് പരിശോധിച്ചതെന്ന് കുറിക്കുക, കാരണം IPv4 ഫലം അതേ ഹോസ്റ്റിലെ IPv6 കണക്ഷനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. WSL നെറ്റ്വർക്കിംഗ് ഡോക്യുമെന്റേഷൻ പരിഹാരം എങ്ങനെയായിരിക്കണം എന്ന് നിർണ്ണയിക്കുന്ന മോഡുകൾ വിവരിക്കുന്നു; MTU സംഖ്യ തന്നെ ഒരു പ്രാദേശിക അളവാണ്, ശുപാർശയല്ല.