VirtualBox-এ NAT নাকি ব্রিজ: ভিএমের VPN কোথায় শেষ হয়

একটি ভার্চুয়াল মেশিন VPN ক্লায়েন্ট চালালে দুইটি ভিন্ন প্রশ্ন একসাথে আসে, আর তাদের উত্তরও ভিন্ন। প্রথমটি হলো অতিথির ভিতরের টানেল হোস্টকে রক্ষা করে কি না, দ্বিতীয়টি হলো হোস্টের টানেল অতিথিকে ঢেকে দেয় কি না। অ্যাডাপ্টার মোড দুইটিই ঠিক করে, VPN সফটওয়্যারের চেয়েও বেশি। NAT অ্যাডাপ্টার হোস্টকে দৃশ্যমান প্রান্তবিন্দু করে, আর ব্রিজ অ্যাডাপ্টার অতিথিকে তার নিজের ঠিকানা দিয়ে নেটওয়ার্কে নামায়।

এনক্রিপ্টেড সেশনটি আসলে কে শেষ করে

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

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

NAT অতিথিকে হোস্টের মতো দেখাতে পুনর্লিখন করে

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

যে অতিথি নিজের ক্লায়েন্ট চালায়, সে ওই টানেল অতিথির ভিতরেই শেষ করে, আর এনক্রিপ্টেড ট্রাফিক একই পুনর্লিখন দিয়ে বেরিয়ে যায়, ফলে হোস্টের অ্যাপ্লিকেশন তাদের নিজের পথ ও নিজের প্রস্থান-ঠিকানা ধরে রাখে। এই মোডে VirtualBox নাম-সমাধানেরও মালিক, এবং --natdnshostresolver1 চালু না থাকলে অতিথির কোয়েরি নিজের ইঞ্জিন দিয়ে পাঠায়। এটি চালু করলে অতিথির খোঁজ হোস্টের রিজলভারে চলে যায়, যা হোস্টের নিজের দৃষ্টি ঠিক থাকলে সমাধান ঠিক করে এবং একইভাবে এমন রিজলভার দিয়ে দেয় যা কেবল টানেলের ভিতরেই থাকতে পারে। সেটিং বদলানোর আগে ভিএম বন্ধ করতে হয়, আর সেটিংটি অতিথির সফটওয়্যারের নয়, অ্যাডাপ্টারের।

ব্রিজ অতিথিকে নিজের লিজ ও নিজের প্রকাশ দেয়

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

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

কেন অতিথি হোস্টের গেটওয়ে হতে পারে না

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

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

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

রিজলভার ও রুট সীমান্ত পেরোয় না

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

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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