হোস্ট VPN সংযোগ করলে Hyper-V গেস্ট DNS হারায়

গেস্ট আজ সকালে ঠিকই ছিল। তারপর হোস্ট Cisco AnyConnect চালু করল এবং VM তার DNS, ডোমেইন ট্রাস্ট ও শেয়ার করা ফোল্ডার হারাল, অথচ ভিতরে কিছুই বদলায়নি। হোস্ট টানেল আর গেস্ট নেটওয়ার্ক আলাদা পথ, একটি সংযোগ করলে অন্যটি সরে না। গেস্টের ভিতর থেকে বাইরের দিকে কাজ করুন, আর কিছু বদলানোর আগে যা দেখছেন তা লিখে রাখুন।

গেস্ট এখনও কী দেখতে পায়

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

সেই তিনটি পাঠ, দুবার নেওয়া, আপনার বেসলাইন। পরের সবকিছু তার বিরুদ্ধে মাপা হয়।

গেস্ট কোন নির্গমন ব্যবহার করছে

Hyper-V দুটি কমান্ডে এর উত্তর দেয়: Get-VMSwitch সুইচগুলো তালিকাভুক্ত করে, আর Get-VMNetworkAdapter -VMName TestVM গেস্ট যে সুইচে যুক্ত তা দেখায়। Default Switch হলো Windows-পরিচালিত NAT নেটওয়ার্ক; একটি এক্সটার্নাল সুইচ ট্রাফিক একটি ফিজিক্যাল অ্যাডাপ্টারে দেয়; একটি ইন্টার্নাল সুইচ কেউ NAT বা রাউটার যোগ না করলে কিছুই বহন করে না। VirtualBox একই তিনটি ধারণা NAT, NAT Network ও bridged হিসেবে উপস্থাপন করে।

মোডই ঠিক করে হোস্ট টানেল আদৌ গুরুত্বপূর্ণ হতে পারে কি না। NAT গেস্ট WinNAT দ্বারা অনূদিত হয় এবং তারপর হোস্ট স্ট্যাক দ্বারা ফরওয়ার্ড হয়, তাই এটি হোস্ট রুট টেবিল অনুসরণ করে; ফুল-টানেল ক্লায়েন্টের সাথে এর ট্রাফিকই সেই ট্রাফিক যা VPN অ্যাডাপ্টারে প্রবেশ করে, আর ক্লায়েন্ট লোকাল সাবনেট ব্লক করলে তা বাদ পড়ে। এক্সটার্নাল সুইচে ব্রিজড গেস্ট হোস্ট রাউটিং পর্যন্ত পৌঁছায়ই না: তার ফ্রেম সরাসরি ফিজিক্যাল NIC থেকে বের হয়, তাই এটি টানেল ও ক্লায়েন্টের লোকাল-ল্যান নীতি দুটোই এড়িয়ে যায়।

Hyper-V-এর সাথে হোস্ট টানেল শেয়ার করা

গেস্টের টানেল দরকার কিন্তু নিজের ক্লায়েন্ট চালাতে না পারলে Windows VPN সংযোগ শেয়ার করতে পারে। VPN অ্যাডাপ্টারের বৈশিষ্ট্য খুলুন, Sharing-এ যান, এবং অন্য নেটওয়ার্ক ব্যবহারকারীদের এর মধ্য দিয়ে সংযোগ করতে দিন। হোম নেটওয়ার্কিং সংযোগটি Hyper-V অ্যাডাপ্টারের দিকে নির্দেশ করুন, vEthernet (Default Switch), তারপর গেস্টের ভিতর থেকে একটি নতুন অনুরোধ পরীক্ষা করুন।

ব্যবস্থাটিকে ল্যাব-সমাধান হিসেবে ধরুন, কারণ এটি ঠিক তেমনই আচরণ করে। সংযোগ বিচ্ছিন্ন, পুনঃসংযোগ বা হোস্ট রিবুটের পরে এটি আবার প্রয়োগ করতে হয়। কিছু Windows 11 বিল্ডে অ্যাডাপ্টারটি ড্রপ-ডাউন থেকে পুরোপুরি অনুপস্থিত, আর তখন এই পথ বন্ধ।

Hyper-V ফিচার পুনঃইনস্টল করা কয়েকটি একগুঁয়ে গেস্টকে বাঁচিয়েছে। এটি শেষের জন্য রাখুন, আর আগে গেস্টের অবস্থা লিখে নিন।

সাবনেট ফিল্টার করা হলে পোর্ট ফরওয়ার্ডিং

যে হোস্ট VPN গেস্টের NAT সাবনেট ফিল্টার করে তা নাম রিজলিউশন নয়, সরাসরি অ্যাক্সেস ভাঙে। VM চলছে, তবু ssh [email protected] ঝুলে থাকে, অথচ হাইপারভাইজার অনুবাদ এখনও কাজ করছে। কাজের প্রয়োজনীয় পোর্টগুলো ফরওয়ার্ড করুন এবং বদলে হোস্ট ঠিকানায় সংযোগ করুন। নিচের Vagrantfile লাইনগুলো SSH আর একটি HTTPS সার্ভিস কভার করে; দুটোই রিলোডের আগে যোগ করতে হয়।

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

নাম রিজলিউশন আলাদা সিদ্ধান্ত এবং এর নিজস্ব সমাধান প্রাপ্য। সেই NAT অ্যাডাপ্টারের জন্য হোস্ট রিজলভার ফিচার চালু করুন, অথবা গেস্টের ভিতরে অভ্যন্তরীণ DNS সার্ভার হাতে কনফিগার করুন। গেস্টকে পাবলিক রিজলভারে নির্দেশ করলে ব্রাউজিং কাজ করে আর প্রতিটি অভ্যন্তরীণ নাম ভাঙে, যা বিভ্রাটের চেয়েও খারাপ কারণ এটি সাফল্যের মতো দেখায়। এমন একটি নাম পরীক্ষা করুন যা কেবল অভ্যন্তরীণ রিজলভার জানে।

যে পরীক্ষা বলে দেয় এটি কাজ করেছে

এই পরিবর্তনগুলোর যেকোনোটির পরে হোস্ট VPN সংযুক্ত থাকা অবস্থায় গেস্টের ভিতর থেকে নতুন অনুরোধ চালান, তার আগে নয়। পুনঃসংযোগের পরে ও রিবুটের পরে শেয়ারিং আবার যাচাই করুন, কারণ যে সমাধান এদের একটিতেই টিকে থাকে তা সমাধান নয়। নিশ্চিত করুন গেস্টের রিজলভার তালিকা তার ট্রাফিক সত্যিই যে নেটওয়ার্ক ব্যবহার করে তার সঙ্গে মেলে। তারপর হোস্ট ঠিকানা থেকে পোর্ট ফরওয়ার্ডিং পরীক্ষা করুন, কারণ গেস্ট থেকে পরীক্ষা করলে কিছুই প্রমাণ হয় না। গেস্টের ভিতর থেকে দুটি PowerShell পরীক্ষা রিজলভার ও ফরওয়ার্ড করা পোর্ট কভার করে:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

প্রতিটি সুইচ বা ড্রাইভার পরিবর্তন তার আনডু ধাপসহ লিখে রাখুন। Microsoft-এর Hyper-V NAT নির্দেশিকা ব্যাখ্যা করে Default Switch আসলে কী, আর এর সঙ্গে সংঘর্ষকারী দ্বিতীয় NAT নেটওয়ার্ক তৈরি করার আগে এটি পড়া উচিত।