Windows-এ VPN ইনস্টল করা, Linux বুটে নেটওয়ার্ক নেই: কী পরীক্ষা করবেন

Windows-এ VPN ইনস্টল করে Linux-এ রিবুট করেন, আর তারযুক্ত সংযোগ মৃত। স্পষ্ট গল্পটি নিজেই লেখা হয়ে যায়: VPN কিছু পিছনে রেখে গেছে। গল্পটি ভুল, কারণ দুটি বুট আলাদা কার্নেল, আলাদা ড্রাইভার, আলাদা রাউটিং টেবিল ও আলাদা রিজলভার চালায়। Windows-এর নেটওয়ার্ক ফিল্টার Linux-এর ভিতরে চলে না, তাই ত্রুটি হয় Linux স্ট্যাকে, নয়তো এমন কিছুতে যা দুটি বুট সত্যিই ভাগ করে, যেমন হার্ডওয়্যার, ফার্মওয়্যার বা রাউটার।

উপসর্গ ও ভুল সিদ্ধান্ত

পর্যবেক্ষণের কাজের অংশটি সময়: পরিবর্তনের পরে ত্রুটিটি দেখা দিয়েছে। অকাজের অংশটি হলো Windows VPN-এর দিকে কারণগত লাফ, যা অন্য অপারেটিং সিস্টেমে চলতে পারে না। দুটিকে আলাদা করাই পুরো কাজ। কেবলে হাত দেওয়ার আগে সময়রেখাটি লিখে নিন।

দুটি বুট যা ভাগ করে তা হলো ভৌত অ্যাডাপ্টার, কেবল, সুইচ পোর্ট এবং উপরের যেকোনো কিছু। এগুলি সত্যিকারের সাধারণ চলক, এবং Linux স্ট্যাক পরীক্ষা করার পরে এগুলি যাচাই করা উচিত।

চারটি কমান্ডে Linux স্ট্যাকের স্ন্যাপশট নিন

কিছু বদলানোর আগে শুধু-পঠন মোডে শুরু করুন ও অবস্থা ধরে রাখুন: ইন্টারফেসের উপস্থিতির জন্য ip -br link, ঠিকানার জন্য ip -br address, IPv4 রুটের জন্য ip route এবং IPv6 গুরুত্বপূর্ণ হলে ip -6 route। ip টুলের রেফারেন্স এই বস্তুগুলিকে আলাদা করে, আর তালিকায় একটি ইন্টারফেস দেখানোই প্রমাণ নয় যে এর কাজ করা ঠিকানা বা ব্যবহারযোগ্য রুট আছে।

আউটপুট একটি ফাইলে সংরক্ষণ করুন যাতে পরে কাজ করা বুটের সাথে মিলিয়ে দেখতে পারেন। যে স্ন্যাপশট আপনি পুনরুৎপাদন করতে পারেন না, তা কেবল একটি অবস্থার স্মৃতি।

এটি লিংক, ঠিকানা, রুট নাকি নাম?

চারটি ভিন্ন ত্রুটি ব্রাউজার থেকে একইরকম দেখায়। ডিভাইসটি সম্পূর্ণ অনুপস্থিত থাকতে পারে, ক্যারিয়ার ছাড়া উপস্থিত থাকতে পারে, সংযুক্ত কিন্তু প্রত্যাশিত ঠিকানা ছাড়া, অথবা ঠিকানাযুক্ত কিন্তু গন্তব্যে রুট ছাড়া। কাঁচা ঠিকানা কাজ করার সময় নাম-রিজলিউশন ব্যর্থ হওয়া পঞ্চম কেস, এবং এটি ড্রাইভারের নয়, রিজলভারের বিষয়।

প্রতিটি কেস ভিন্ন কাজের দিকে নির্দেশ করে: অনুপস্থিত ডিভাইসের জন্য ড্রাইভার বা ফার্মওয়্যার, ক্যারিয়ার না থাকলে কেবলিং বা সুইচ, ঠিকানা না থাকলে DHCP বা স্ট্যাটিক কনফিগারেশন, আর পথ না থাকলে রাউটিং বা পলিসি। রিজলভারের সমস্যা systemd-resolved, NetworkManager বা স্থানীয় DNS কনফিগারেশনের দিকে নির্দেশ করে।

Linux ইনস্টলেশনের নিজস্ব VPN বা স্থায়ী ফায়ারওয়াল কনফিগারেশন আছে কি না দেখুন। স্থানীয় টানেল বা nftables নিয়মের সেট Linux-পক্ষের কারণ, এবং চলমান নয় এমন একটি Windows প্রোগ্রামের চেয়ে এটি অনেক বেশি সম্ভাব্য ব্যাখ্যা।

তারপর বুট ট্রানজিশন তুলনা করুন

Windows Fast Startup হলো একটি হাইব্রিড শাটডাউন যা সম্পূর্ণ বুট না করে কার্নেল সেশন অবস্থা ধরে রাখে। Microsoft-এর পাওয়ার-স্টেট ডকুমেন্টেশন এটিকে রিস্টার্ট ও সম্পূর্ণ শাটডাউন থেকে আলাদা করে, তাই একই হার্ডওয়্যার দুটি ট্রানজিশনে ভিন্নভাবে আচরণ করতে পারে।

ত্রুটিটি যদি একটি অপারেটিং সিস্টেম থেকে অন্যটিতে যাওয়ার উপর নির্ভর করে, তবে কাজ সংরক্ষণ করে নথিভুক্ত রিস্টার্ট বা সম্পূর্ণ শাটডাউনকে স্বাভাবিক পথের সাথে তুলনা করুন। ট্রানজিশন অনুসরণকারী ফলাফল ড্রাইভার, ডিভাইস বা ফার্মওয়্যার অবস্থা পরীক্ষা করা ন্যায্য করে, আর এটি নিজে প্রমাণ করে না যে Fast Startup নির্দিষ্ট অ্যাডাপ্টার ত্রুটি ঘটিয়েছে।

কোন OS শেষে অ্যাডাপ্টার ব্যবহার করেছে, ট্রানজিশনের ধরন, Linux লিংক অবস্থা এবং প্রথম যে অপারেশনটি ব্যর্থ হয়েছে তা লিখে রাখুন। কোন স্ট্যাক ভেঙেছে না জেনে উভয় ইনস্টলেশন থেকে VPN সফটওয়্যার সরানোর চেয়ে পুনরাবৃত্তিযোগ্য কোল্ড-স্টার্ট বনাম ওয়ার্ম-ট্রানজিশন পার্থক্য অনেক বেশি মূল্যবান।

কী বদলাবেন না

প্রথম পদক্ষেপ হিসাবে উভয় নেটওয়ার্ক স্ট্যাক রিসেট করবেন না। এটি তুলনাটি নষ্ট করে এবং প্রায়শই কিছুই ঠিক করে না, কারণ প্রকৃত কারণ কখনও চিহ্নিত হয়নি। Linux মেরামতের জন্য Windows VPN পুনরায় ইনস্টল করবেন না, আর বুট ট্রানজিশন ত্রুটির সাথে মিলে গেছে বলে ফার্মওয়্যার সেটিংস এলোমেলোভাবে বদলাবেন না।

ip টুলের রেফারেন্স উপরে ব্যবহৃত লিংক, ঠিকানা ও রুট বস্তুগুলি নথিভুক্ত করে। আগে Linux দিকটি পড়ুন, স্ন্যাপশটটি রাখুন, এবং কেবল তারপর ভাবুন সাধারণ হার্ডওয়্যার স্তরটি তদন্ত করার যোগ্য কি না।