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 संख्या स्वयं स्थानीय मापन हो, सिफारिस होइन।