WSL2 मधील Git VPN वर अडकतो: इंटरफेस MTU की मार्ग?
Git प्रमाणीकरण करते आणि नंतर WSL2 मध्ये लटकते? Linux इंटरफेसची Windows VPN अडॅप्टरशी तुलना करा, एक लहान मूल्य तपासा आणि त्याचे आयुष्य नियोजित करा.
क्लोन प्रमाणीकरण करते, ऑब्जेक्टची संख्या दिसते, आणि नंतर काही मिनिटे काहीच हलत नाही। 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 संख्या स्वतः स्थानिक मापन आहे, शिफारस नाही।