VPN হোস্টে না VM-এর ভিতরে চালাবেন? সিদ্ধান্তের নির্দেশিকা
টানেলের মালিক ঠিক করে কী কী ঢাকে। হোস্ট বা গেস্ট বসানো বেছে নিন, তারপর গেস্টের ভিতরে রুট, DNS ও এক্সিট পরীক্ষা দিয়ে তা নিশ্চিত করুন।
গেস্টের ভিতরে টানেল বানানো আর হোস্টে সেটি বানানো—দুটোই ব্রাউজার যে ঠিকানা জানায় তা বদলে দেয়, আর মিল সেখানেই শেষ। গেস্টের মালিকানার টানেল তার কী, তার ডিফল্ট রুট আর তার রিজলভার গেস্ট কার্নেলের ভিতরে রাখে, আর হোস্ট এনক্রিপ্ট করা প্যাকেট একটি দূরবর্তী ঠিকানায় পাঠায়। হোস্টের মালিকানার টানেল এর উল্টো ছবি: হোস্ট ক্লায়েন্ট সেশন ধরে রাখে ও রুট ও নীতি প্রয়োগ করে, আর গেস্ট যা বেরোয় তা ধার করে। ভুল মালিক বাছলে পরের প্রতিটি উপসর্গ আপনাকে ভুল মেশিনে পাঠাবে। দুটি কমান্ড প্রায় এক মিনিটে প্রশ্নটি মিটিয়ে দেয়, আর এই নির্দেশিকার বাকিটা হলো উত্তরটা নিয়ে কী করবেন।
ক্লায়েন্ট ছোঁয়ার আগেই মালিক ঠিক করুন
নিয়মটা হলো সাইফারটেক্সট কোথায় তৈরি হয় তা নিয়ে, কোন মেশিন VPN আইকন দেখায় তা নিয়ে নয়। গেস্ট যদি এটি তৈরি করে, তবে গেস্টের VPN সার্ভারে একটি কাজ করা রুট দরকার এবং হোস্ট থেকে আর কিছুই নয়। হোস্ট যদি এটি তৈরি করে, তবে হোস্ট ক্লায়েন্ট স্থানীয় ট্রাফিকে যে নীতি চাপায় তা সত্ত্বেও গেস্টের হোস্ট-পথ টিকে থাকতে হবে।
সাধারণত তিনটি প্রশ্নই আপনার জন্য বসানো বেছে দেয়। গেস্টের ট্রাফিকে কি হোস্টের কর্পোরেট ক্লায়েন্ট পেরোতে হবে? তাহলে টানেল গেস্টের ভিতরে। একাধিক গেস্টের কি একটি ক্রেডেনশিয়াল আর একটি এক্সিট ঠিকানা দরকার? তাহলে এটি হোস্টে, ইচ্ছাকৃতভাবে ফরওয়ার্ডিং সেট করে। গেস্টের ট্রাফিকে কি হোস্টের VPN থেকে পুরোপুরি দূরে থাকতে হবে? তাহলে গেস্ট-টানেলই একমাত্র ব্যবস্থা যা এটি নির্মাণগতভাবেই দেয়।
উত্তরটি VM-এর নামের পাশে এক লাইনে লিখে রাখুন: guest-owned বা host-owned। ছয়টি মেশিনের ল্যাবে ওই নোটটি নিচের যেকোনো ধাপের চেয়ে বেশি সময় বাঁচায়, কারণ এটি আপনাকে এমন টানেলের সমস্যা খুঁজতে দেয় না যা আপনি যে মেশিনে লগইন করেছেন সেখানে ছিলই না।
WSL1 আর WSL2 পরস্পরবিরোধী দুই কেস
WSL1 কোনো ভার্চুয়াল মেশিন নয়, তাই বসানোর প্রশ্নটা বেশিরভাগ ক্ষেত্রেই মিলিয়ে যায়। এর Linux বাইনারিগুলো একটি অনুবাদ স্তর দিয়ে Windows নেটওয়ার্ক স্ট্যাকের ওপর চলে, আর Linux VPN ক্লায়েন্টের কনফিগার করার মতো স্বতন্ত্র ইন্টারফেস থাকে না। যে ব্যবস্থাটি কাজ করে তা হলো Windows-পাশের টানেল, আর ডিস্ট্রিবিউশন কিছু না মালিকানায় নিয়েই ফলাফলটি ব্যবহার করে।
WSL2 ঠিক উল্টো। এটি Hyper-V ভার্চুয়াল সুইচের পেছনে একটি হালকা ইউটিলিটি VM-এ সত্যিকারের কার্নেল চালায়, আর এর ঠিকানা-স্থান হোস্ট-পাশের অ্যাডাপ্টার দিয়ে NAT করা হয়। তাই ডিস্ট্রিবিউশনের ভিতরের Linux ক্লায়েন্ট আচরণ করে যেমনটি একটি ফিজিক্যাল Linux বক্সে করত: এটি tun0 বা wg0 তৈরি করে, নিজের রুট বসায়, আর কাজ করে। ব্যর্থতাটি থাকে হোস্টের দিকে। যখন Windows VPN ক্লায়েন্ট এমন নীতি নিয়ে সংযোগ করে যা স্থানীয় নেটওয়ার্কে ট্রাফিক আটকায়, তখন এটি WSL2 সাবনেটকে অবিশ্বস্ত স্থানীয় নেটওয়ার্ক ধরে NAT পথটি কেটে দেয়। তখন ডিস্ট্রিবিউশন DNS আর বাইরের অ্যাক্সেস হারায়, অথচ তার নিজের টানেল তখনো সুস্থ: wg show হ্যান্ডশেক জানায়, ip route ঠিক দেখায়, আর curl ঝুলে থাকে।
কোন সমাধান ব্যবহার করতে পারবেন তা নির্ভর করে Windows বিল্ডের ওপর। পুরোনোটি হলো WSL সাবনেটের জন্য হোস্ট-ক্লায়েন্টে একটি ব্যতিক্রম, যা ক্লায়েন্টের স্থানীয়-নেটওয়ার্ক বা বিভক্ত-টানেল সেটিংসের নিচে যোগ করা হয়। নতুনটি, যে Windows 11 বিল্ডগুলো এটি সমর্থন করে সেগুলোতে, হলো মিররড নেটওয়ার্কিং: %UserProfile%\.wslconfig-এর [wsl2] অংশে networkingMode=mirrored বসান, wsl --shutdown চালান, আর ডিস্ট্রিবিউশন ব্যক্তিগত NAT সাবনেটের বদলে হোস্টের ইন্টারফেস ভাগ করে নেবে। মিররড মোড localhost আর ইনবাউন্ড পোর্টের আচরণও বদলায়, তাই এটিকে টগল নয়, মাইগ্রেশন হিসেবে ধরুন।
NAT, ব্রিজড, আর হোস্ট কী দেখতে পায়
NAT-এর অধীনে গেস্টের টানেল প্যাকেটগুলো VPN সার্ভারের পাবলিক ঠিকানায় ঠিকানা পায় আর এনক্রিপ্ট করা UDP বা TCP হিসেবে হোস্ট অ্যাডাপ্টার দিয়ে বেরোয়। হোস্ট একটি ফ্লো আর তার বাইট-সংখ্যা দেখে, ভিতরের গন্তব্যগুলো সম্পর্কে কিছুই নয়। ব্রিজড অ্যাডাপ্টারের অধীনে গেস্টের ফিজিক্যাল LAN-এ নিজের 2-স্তরের পরিচয় থাকে, নিজের DHCP ইজারা নেয়, আর MAC-ভিত্তিক যেকোনো নীতির কাছে দ্বিতীয় ডিভাইসের মতো দেখায়। কোনো মোডই হোস্টকে টানেলের পেলোড পড়তে দেয় না; ব্রিজড গেস্ট শুধু তার চারপাশের নেটওয়ার্কের কাছে অনেক বেশি দৃশ্যমান।
আইসোলেশনেরও একটি নিম্নসীমা আছে। গেস্ট যে মেশিন তার মেমোরির মালিক তার থেকে লুকাতে পারে না, আর যে হোস্ট নিয়ন্ত্রণ করে সে গেস্টের RAM থেকে কী পড়ে নিতে পারে। গেস্ট-টানেল আপনাকে দেয় একটি রাউটিং সীমা আর একটি ম্যালওয়্যার সীমা, ল্যাপটপ হাতে ধরা মানুষটির থেকে সুরক্ষা নয়। নথিভুক্ত অ্যাডাপ্টার মোডগুলো বেছে নেওয়ার সময় খোলা রাখা ভালো, কারণ মোডটি হোস্ট কী দেখে আর LAN কী দেখে—দুটোই বদলে দেয়।
নির্দেশিকা: বসান, কনফিগার করুন, প্রমাণ করুন
এই চারটি পরীক্ষা একটি নতুন গেস্ট শেলে ক্রমে চালান, আর আপনি যে মালিক লিখে রেখেছেন তার সঙ্গে যে প্রথমটি মেলে না সেখানেই থামুন।
ip route get 1.1.1.1যদিtun0বাwg0ফেরায় তবে গেস্ট-মালিকানা, আর ব্যক্তিগত পরবর্তী হপসহeth0ফেরালে হোস্ট-মালিকানা।resolvectl query example.com, অথবা যেখানে গেস্ট কোনো রিজলভার সেবা চালায় না সেখানে/etc/resolv.confপড়ুন। যে টানেল ট্রাফিক বহন করে কিন্তু DNS নয়, সেটিই সবচেয়ে সাধারণ অর্ধ-কনফিগার করা অবস্থা।- এক্সিট মিলান: গেস্টে
curl -4 -s https://ifconfig.meআর হোস্টেcurl.exe -4 -s https://ifconfig.me। আলাদা ঠিকানা মানে গেস্টই টানেলের মালিক, আর VPN-এ থাকা হোস্টের সঙ্গে ঘরের ISP দেখানো গেস্ট হলো কিছুই-উত্তরাধিকার-পায়নি কেসটি। -6দিয়ে দুটোই আবার করুন। শুধু-v4 টানেল v6 ফাঁস করে, যদি না ক্লায়েন্ট সেটি আটকায় বা রুট করে, আর অনেক ক্লায়েন্ট ডিফল্টে v6 ফিজিক্যাল ইন্টারফেসেই রেখে দেয়।
হোস্ট-গেটওয়ে নকশায়, যেখানে একাধিক গেস্ট একটি টানেল ভাগ করে, হোস্টকে ফরওয়ার্ড ও অনুবাদ করতে হয়। Linux হোস্টে এটি তিনটি টুকরো, আর যেকোনো একটি না থাকলেই গেস্ট চুপচাপ তার সাধারণ রুটে ফিরে যায়:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard-এর দিকে হোস্ট পিয়ারের AllowedIPs-এ গেস্ট সাবনেট থাকতে হবে, যেমন 192.168.122.0/24, নইলে ফেরত প্যাকেট কখনো পৌঁছায় না আর সেটআপটা ফায়ারওয়াল সমস্যার মতো দেখায়। Windows হোস্ট Internet Connection Sharing বা Hyper-V সুইচে NAT নিয়ম দিয়ে একই ফল পায়, আর একই রিটার্ন-পাথ পরীক্ষা দরকার।
যখন বিন্যাসটি এখনো খোলা, এই সারণিটি সবচেয়ে বেশি আসা ব্যবস্থাগুলো ঢাকে:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
দুটি টানেল, দুটি গেস্ট, আর তাদের মধ্যে দ্বন্দ্ব
যখন একসঙ্গে দুটি এক্সিট দরকার, যে নকশাটি টেকে তা হলো প্রতি গেস্টে একটি টানেল। প্রতিটি VM নিজের ডিফল্ট রুট আর রিজলভার রাখে, হোস্ট সাধারণ নেটওয়ার্কেই থাকে, আর দুটি টানেল একই রাউটিং টেবিল নিয়ে কখনো ঝগড়া করে না। দুটি গেস্টকে ব্রিজে জোড়া দিলেও তাদের রুট এক হয় না: ভার্চুয়াল নেটওয়ার্ক একটি পথ দেয়, আর প্রতিটি ক্লায়েন্টকে এখনো বলতে হয় যে এই স্থানীয় ট্রাফিক টানেল এড়িয়ে যেতে পারে।
হোস্ট টানেল আর গেস্ট টানেল একসঙ্গে চালানো বৈধ, আর ইচ্ছাকৃত নেস্টিং মাঝে মাঝে ঠিক তাই যা আপনি চান—গেস্ট তার নিজের টানেল দিয়ে বেরোয় আর সেই টানেল হোস্টের টানেল দিয়ে বেরোয়। এটিকে বিভ্রাটে বদলে দেয় এই যে কেউ লিখে রাখেনি কোন প্রান্তে কোন স্তর দিয়ে পৌঁছাতে হবে। গন্তব্য আর মালিকের দুই-কলামের তালিকা রাখুন, তাহলেই রুট দ্বন্দ্ব এক বিকেলের আবিষ্কারের বদলে এক নজরের খোঁজ হয়ে যায়।
যাচাই করুন, তারপর পুনরুদ্ধার মালিকের কাছেই রাখুন
গেস্টের ভিতর থেকে পরীক্ষা করুন একটি নতুন অ্যাপ্লিকেশন প্রসেস দিয়ে: ট্রাফিক, নাম-সমাধান, দুই ঠিকানা-পরিবার, আর টানেল পড়ে গেলে কী হয়। হোস্টের VPN আইকন গেস্টের কভারেজ নিয়ে কিছুই বলে না, আর এই পুরো ক্ষেত্রে এটিই সবচেয়ে সাধারণ ভুল নিশ্চয়তা।
পুনরুদ্ধারও মালিকেরই। গেস্ট-মালিকানার টানেল গেস্টের নিজের ক্লায়েন্ট আর সে যে রুটগুলো লিখেছিল তা দিয়ে ফেরানো হয়। হোস্ট-মালিকানার নকশা ফেরানো হয় হোস্টের বুট-ক্রম দিয়ে, আর ফরওয়ার্ডিং নিয়মগুলো রিবুটে টেকে না যদি না কোনো unit বা স্টার্টআপ টাস্ক সেগুলো আবার প্রয়োগ করে। পুনরুদ্ধার করা স্ন্যাপশট হলো একটি ডিপ্লয়মেন্ট, আনডু নয়, কারণ এটি ডিস্কের সঙ্গে পুরোনো ক্রেডেনশিয়াল আর পুরোনো রুট ফিরিয়ে আনে। কাজ শেষ বলার আগে নিশ্চিত করুন যে মালিক এখনো আপনার লেখা লাইনের সঙ্গে মেলে, DNS আর দুই ঠিকানা-পরিবার গেস্টের ভিতরে সমাধান হয়, মৃত টানেল কালোগর্তের বদলে ব্যবহারযোগ্য নেটওয়ার্ক রেখে যায়, আর রিবুট বা স্ন্যাপশট পুনরুদ্ধার একই অবস্থা ফিরিয়ে দেয়।