کلون تصدیق کرتا ہے، اشیاء کی تعداد ظاہر ہوتی ہے، اور پھر کئی منٹ تک کچھ نہیں ہلتا۔ 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"'

Linux والا حصہ تقسیم کے اندر چلائیں نہ کہ آؤٹ پٹ کو Windows شیل میں چسپاں کریں، کیونکہ انٹرفیس کے نام اور راستے کا انتخاب صرف وہیں معنی رکھتے ہیں۔ 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 کا عدد بذات خود مقامی پیمائش ہے، سفارش نہیں۔

متعلقہ مضامین