VMware-এর ব্রিজ করা গেস্ট OpenVPN-এর পরে তার নেটওয়ার্ক হারিয়েছে

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

গেস্ট বদলায়নি, ব্রিজ বদলেছে

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

VMnet0 ডিফল্টভাবে স্বয়ংক্রিয়-তে সেট থাকে, অর্থাৎ হাইপারভাইজার প্রতিবার ব্রিজ বানানোর সময় একটি হোস্ট অ্যাডাপ্টার বেছে নেয়। নতুন ইনস্টল করা ভার্চুয়াল অ্যাডাপ্টার সেই দলে ঢুকে যায়, এবং যদি সেটি বেছে নেওয়া হয়, তবে গেস্টের পাঠানো প্রতিটি ফ্রেম ভৌত সুইচ পোর্টের বদলে টানেল ডিভাইসে যায়।

ব্রিজ পিন করুন বা গেস্টকে রুট করুন

প্রথম শাখাটি তখন সঠিক যখন গেস্টকে ভৌত LAN-এ সমান সদস্য হতে হবে: ব্রিজকে বেছে নিতে দেওয়া বন্ধ করুন, এবং অ্যাডাপ্টারের নাম স্পষ্টভাবে নিন। দ্বিতীয় শাখাটি তখন প্রযোজ্য যখন গেস্টকে কর্পোরেট টানেল ব্যবহার করতে হবে, এবং সেই ক্ষেত্রে ব্রিজ কখনোই সঠিক নকশা ছিল না, কারণ ব্রিজ করা গেস্ট হোস্টের VPN রুট উত্তরাধিকারে পায় না।

এটি আগে ঠিক করুন, কারণ দুটি উত্তর ভিন্ন কাজের দিকে নিয়ে যায়। ক্রম উল্টে দিলে সঠিকভাবে পিন করা ব্রিজ তৈরি হয়, কিন্তু তা এমন গেস্টের সাথে যুক্ত হয় যাকে কখনো ব্রিজ করা উচিত হয়নি।

প্রথম শাখার জন্য হোস্টে ভার্চুয়াল নেটওয়ার্ক এডিটর খুলুন, VMnet0 বেছে নিন এবং স্বয়ংক্রিয়-কে ভৌত অ্যাডাপ্টার দিয়ে বদলান। যদি একাধিক অ্যাডাপ্টার থাকে, স্বয়ংক্রিয় সেটিংসের তালিকা ব্যবহার করুন এবং যেকোনো কিছু থেকে টিক সরিয়ে দিন যা কখনো গেস্ট ট্রাফিক বহন করা উচিত নয়: OpenVPN TAP বা Wintun ডিভাইস, সাথে Hyper-V, WSL, Docker ও loopback অ্যাডাপ্টার। ল্যাপটপে তারযুক্ত ও তারবিহীন দুটি ভৌত অ্যাডাপ্টারই টিক দেওয়া রাখুন, নইলে পরের বার ব্যবহারকারী এটি ডকে লাগালে গেস্ট তার ব্রিজ হারাবে।

তিনটি শর্ত যা পছন্দ ঠিক করে

ব্রিজ আদৌ উপযুক্ত কি না তা নির্ভর করে গেস্টটি কী কাজে। যদি গেস্টকে LAN-এ নিজের আলাদা হোস্ট হিসেবে দেখা দিতে হয়, নিজের ঠিকানা ও নিজের আগত নাগাল নিয়ে, তবে ব্রিজই সঠিক মডেল এবং পিন করাই পুরো সংশোধন। যদি গেস্টের কেবল বহির্গামী প্রবেশাধিকার দরকার হয়, তবে শুধু-হোস্ট বা NAT নেটওয়ার্ক সহজ এবং অ্যাডাপ্টার বদলের প্রতি প্রতিরোধী।

যদি গেস্টকে হোস্টের মতো একই টানেল ব্যবহার করতে হয়, না ব্রিজ মোড না পিন করা অ্যাডাপ্টার সাহায্য করে, কারণ গেস্টের ট্রাফিক কখনো হোস্টের রাউটিং সিদ্ধান্তে ঢোকে না। সেই ক্ষেত্রে হোস্টে রাউট করা বা অনূদিত পথ দরকার, এবং অ্যাডাপ্টারের পছন্দ অপ্রাসঙ্গিক হয়ে যায়।

VMware Player-এর ইন্টারফেসে কোনো নেটওয়ার্ক এডিটর নেই, তাই যে হোস্ট কেবল Player চালায় তার এই সেটিংসে পৌঁছাতে আলাদা এডিটর বা Workstation ইনস্টল দরকার। এই সীমাবদ্ধতা কখনো কখনো একাই পদ্ধতি ঠিক করে দেয়।

গেস্টের ভিতর থেকে ফলাফল পড়ুন

ভার্চুয়াল NIC আবার চালু করুন, বা গেস্ট আবার চালু করুন, যাতে এটি আবার লিজ চায়। তারপর পড়ুন যে এটি সত্যিই কী পেয়েছে, না যে হোস্ট মনে করে এটি কনফিগার করেছে।

ipconfig /all
ip addr
ip route

সেই আউটপুটে দুটি ফিল্ড পড়ুন এবং বাকিটা আপাতত উপেক্ষা করুন। গেটওয়ে LAN রাউটার হওয়া উচিত, এবং অ্যাডাপ্টারের বিবরণে টানেলের বদলে VMware Ethernet ডিভাইসের নাম থাকা উচিত। 169.254.0.0/16-এর মধ্যে স্বয়ং-বরাদ্দ ঠিকানার অর্থ কোনো DHCP সার্ভার উত্তর দেয়নি, এবং গেস্টের দিক থেকে টানেল অ্যাডাপ্টারের উপর ব্রিজ ঠিক এমনই দেখায়।

আর কিছু বদলানোর আগে আরেকটি পার্থক্য করা উচিত। যে গেস্ট রাউটার পর্যন্ত পৌঁছায় কিন্তু ইন্টারনেট পর্যন্ত নয়, তার ব্রিজ কাজ করছে আর সমস্যা উপরের দিকে। যে গেস্ট টানেলের পরিসরে ঠিকানা পায়, সে এখনও ভুল ডিভাইসে যুক্ত। TAP অ্যাডাপ্টার বন্ধ করা দুই ক্ষেত্রের কোনোটিরই সমাধান নয়, কারণ OpenVPN সার্ভিসের এটি দরকার।