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 సంఖ్య స్వయంగా స్థానిక కొలత, సిఫార్సు కాదు.