VirtualBox NAT গেস্টের ভিতরে SOCKS সার্ভারে পৌঁছানো

VirtualBox গেস্টের ভিতরে থাকা SOCKS পরিষেবার দুটি আলাদা নাগালের শর্ত আছে: VirtualBox-কে সংযোগটি গেস্টের কাছে পৌঁছাতে হবে, এবং গেস্টের পরিষেবাকে তা গ্রহণ করতে হবে।

যে VM-এর প্রথম অ্যাডাপ্টার সাধারণ NAT ব্যবহার করে, তার জন্য VirtualBox 7.1 এই রূপে পোর্ট-ফরওয়ার্ডিং নিয়ম নথিভুক্ত করে। VM বন্ধ থাকা অবস্থায়:

VBoxManage modifyvm "Proxy VM" --nat-pf1 "socks,tcp,127.0.0.1,1080,,1080"

প্রয়োজন অনুযায়ী VM-এর নাম ও পোর্ট বদলান। এরপর হোস্ট অ্যাপ্লিকেশন 127.0.0.1:1080-এ SOCKS বেছে নেয়। হোস্টের দিক 127.0.0.1-এ বাঁধলে এই প্রবেশবিন্দু হোস্টের মধ্যেই সীমাবদ্ধ থাকে।

খালি গেস্ট-ঠিকানার ঘরটি ধরে নেয় যে গেস্ট NAT ইঞ্জিনের অন্তর্নির্মিত DHCP বরাদ্দ ব্যবহার করে। গেস্ট যদি বদলে স্থির ঠিকানা ব্যবহার করে, তবে সেই ঠিকানাটি নিয়মে দিন। শেষের 1080 হলো গেস্ট পরিষেবার পোর্ট; এটি হোস্ট পোর্টের সমান হওয়া আবশ্যক নয়।

গেস্টের লিসেনার এখনও একটি নেটওয়ার্ক পরিষেবা

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

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

এই TCP নিয়মটি TCP-র উপর একটি SOCKS সংযোগ কভার করে। এটি নিজে থেকে SOCKS5 UDP relay-এর প্রয়োজনীয় অতিরিক্ত UDP পথ দেয় না।