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 সংখ্যাটি নিজেই স্থানীয় পরিমাপ, সুপারিশ নয়।