NAT বনাম ব্রিজড VM নেটওয়ার্কিং: VPN ট্রাফিক কোনটি বহন করে?

NAT গেস্টরা হোস্টের টানেল ধার করে শুধু তখনই, যখন ক্লায়েন্ট রুট অনুযায়ী টানেল করে; ব্রিজড গেস্টরা নিজেরাই রুট করে। গেস্ট পরীক্ষা করুন, তারপর মানানসই মোড বেছে নিন।

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

NAT গেস্টকে হাইপারভাইজার কোডের পেছনে রাখে, যেখানে হোস্ট রুট প্রযোজ্য

VirtualBox-এ NAT গেস্ট 10.0.2.0/24-এ বসে, ভার্চুয়াল গেটওয়ে 10.0.2.2, DNS প্রক্সি 10.0.2.3, এবং ফিজিক্যাল নেটওয়ার্কে নিজের কোনো রুট নেই। আউটবাউন্ড প্যাকেট NAT ইঞ্জিন নেয়, উৎস হোস্ট হবে এমনভাবে পুনর্লিখন করে এবং হোস্টের IP স্ট্যাকে পাঠায়। সেখান থেকে গেস্টের ট্রাফিক হোস্ট প্রবাহ, এবং রুট লুকআপ গন্তব্য অনুযায়ী হয়: হোস্টে 0.0.0.0/1 এবং 128.0.0.0/1 ইনস্টল করা ফুল-টানেল ক্লায়েন্ট VM আছে জেনেও না জেনে তা ধরে নেয়। Oracle-এর VirtualBox নেটওয়ার্কিং অধ্যায় আপনার বিল্ডে ঠিকানাগুলো নিশ্চিত করতে চাইলে এই ডিফল্টগুলো তালিকাভুক্ত করে।

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

ব্রিজড মোড গেস্টকে ফিজিক্যাল LAN-এ নিজের জায়গা দেয়

ব্রিজড গেস্ট একটি রিয়েল অ্যাডাপ্টারের সাথে যুক্ত ভার্চুয়াল NIC পায়, নিজের MAC ঠিকানা পায়, এবং ফিজিক্যাল নেটওয়ার্ক থেকে DHCP লিজ নেয়। তার ডিফল্ট গেটওয়ে হাইপারভাইজার নয়, LAN রাউটার, এবং তার ফ্রেম ওই অ্যাডাপ্টার দিয়ে তারে যায়। হোস্টের টানেল রুট হোস্টের টেবিলে থাকে এবং কখনো জিজ্ঞাসা করা হয় না, কারণ গেস্টের ফ্রেম কখনো হোস্টের IP স্ট্যাকে ঢোকে না।

এটি দুই দিকেই কাটে। mDNS এবং SMB ব্রাউজিং কাজ শুরু করে কারণ গেস্ট LAN ব্রডকাস্ট ট্রাফিক দেখে, এবং গেস্ট একই সেগমেন্টের অন্য মেশিন থেকে হোস্ট ফায়ারওয়াল ছাড়াই পৌঁছানো যায়। ব্রিজও বিদ্যমান টানেলের মধ্য দিয়ে গেস্টকে ঠেলে দেওয়ার উপায় নয়: VM-কে হোস্টের WireGuard বা OpenVPN ইন্টারফেসে যুক্ত করা VirtualBox বা libvirt আপনার জন্য করে না। কোনো ব্রিজড গেস্টকে টানেল করতে হলে টানেলটি ওই LAN-এর কোথাও শেষ হতে হবে।

যে পরীক্ষা তর্ক শেষ করে

উভয় মোডে একই চেক চালান এবং উত্তরগুলো লিখে রাখুন:

  • হোস্টে curl -s https://ifconfig.me পাবলিক v4 ঠিকানা দেয়।
  • গেস্টে একই কমান্ড, সঙ্গে ip route Linux-এ বা Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windows-এ ডিফল্ট গেটওয়ের জন্য।
  • রিজলভার পরিচয়: resolvectl status বা cat /etc/resolv.conf গেস্টে, দেখতে যে এটি 10.0.2.3-এ নাকি LAN সার্ভারে নির্দেশ করে।
  • ঠিকানা পরিবার: ip -6 addr show scope global এবং একটি v6 অনুরোধ, কারণ v4 টানেল গেস্টের থাকতে পারে এমন গ্লোবাল v6 ঠিকানা সম্পর্কে কিছু বলে না।

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

দুটি সংকেত মিথ্যা বলে। সফল ping পৌঁছনো প্রমাণ করে, নির্গমন পথ নয়। আর DNS হোস্ট রিজলভারের মাধ্যমে 10.0.2.3 প্রক্সি উত্তর দিতে পারে, যখন TCP অন্য রুট নেয়, এভাবেই এমন পৃষ্ঠা আসে যা লোড হয় আর লগইন যা কখনো শেষ হয় না।

কোন মোড কাজের জন্য মানায়

মোড একটি রাউটিং সিদ্ধান্ত, তাই অভ্যাস নয়, প্রয়োজন থেকে এটি বাছুন:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

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

যে ব্যর্থতাগুলো VPN-এর ঘাড়ে চাপে

Windows-এ NAT অনুবাদ VirtualBox VM প্রসেসের ভেতরে চলে, তাই প্রতি-অ্যাপ ক্লায়েন্টের তালিকায় ভার্চুয়াল মেশিনের জন্য সার্বিক নিয়মের বদলে ঠিক ওই ইমেজ দরকার। ক্লায়েন্ট আপডেট প্রসেস অনুমোদন তালিকা পুনর্গঠন করলে NAT গেস্টরা আগে কভারেজ হারায়, এবং প্রতিবেদনটি এমন VM-এর মতো পড়ায় যা LAN-এ পৌঁছায় কিন্তু ইন্টারনেটে নয়, অথচ হোস্ট ঠিক আছে।

Wi-Fi-তে ব্রিজ করা আরেকটি চিরচেনা ঘটনা। অ্যাক্সেস পয়েন্ট বিদেশি উৎস MAC বহনকারী ফ্রেম খুব কমই ফরোয়ার্ড করে, তাই wlan0-এ ব্রিজ হয় পুরোপুরি ব্যর্থ হয়, নাহয় কাজ করে যতক্ষণ না AP-তে ক্লায়েন্ট আইসোলেশন তা ফেলে দিতে শুরু করে। VirtualBox তার তালিকায় ওয়্যারলেস অ্যাডাপ্টার দেখাবে। হোস্ট Wi-Fi-তে থাকলে এবং গেস্ট ব্রিজ করতে হলে অনুমান নয়, পরীক্ষার পরিকল্পনা করুন।

MTU তৃতীয়টি। ব্রিজড গেস্ট LAN-এর 1500 বাইট MTU রাখে, এবং নিজের WireGuard ক্লায়েন্ট 1420-এ চালালে বড় TLS হ্যান্ডশেক আটকে যায়, ছোট অনুরোধ সফল হয়। NAT-এর অধীনে হোস্ট টানেলের MTU হোস্টের সমস্যা, কিন্তু গেস্ট তখনো 1500-এ বিশ্বাস করে, এবং don't-fragment বিট দেওয়া UDP একইভাবে কালোগর্তে পড়ে।

মোড লিখে রাখুন, তারপর অ্যাডাপ্টার বদলালেই আবার যাচাই করুন

মোড, ব্রিজ যে হোস্ট ইন্টারফেস ব্যবহার করে, গেস্টের ডিফল্ট গেটওয়ে, তার রিজলভার এবং তার v4 ও v6 নির্গমন ঠিকানা লিখে রাখুন। ওই রেকর্ডই পরের ব্যর্থতাকে সস্তা করে: ল্যাপটপ ডক থেকে Wi-Fi-তে গেলে ব্রিজড গেস্ট ব্রিজ অনুসরণ করে অন্য ফিজিক্যাল অ্যাডাপ্টারে যায় এবং অন্য সাবনেটে পুনরায় লিজ নিতে পারে, আর NAT গেস্ট তার 10.0.2.x ঠিকানা রাখে এবং চুপচাপ অন্য আপলিংক উত্তরাধিকারে পায়।

টিকিট বন্ধ করার আগে এগুলোর প্রতিটি নিশ্চিত করুন:

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

সম্পর্কিত নিবন্ধ