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 સંખ્યા પોતે સ્થાનિક માપ છે, સિફારસ નહીં.