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 எண் தானே உள்ளூர் அளவீடு, பரிந்துரை அல்ல.