আপনার VM কি হোস্টের VPN ব্যবহার করে? গেস্টের ভেতর থেকে পরীক্ষা করুন

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

পরীক্ষাটি গেস্টের ভেতরে চালাতে হবে, এবং এটি কী মাপল তা নাম দিয়ে বলতে হবে।

হোস্টের ব্রাউজারে নয়, গেস্টের ভেতরে শুরু করুন

প্রথমে হাইপারভাইজারের নেটওয়ার্ক মোড লিখে রাখুন: NAT, bridged, host-only বা macvtap। NAT মোডে হোস্ট গেস্টের ট্রাফিক রুট করে, তাই ক্লায়েন্ট কীভাবে রুট ইনস্টল করে তার উপর নির্ভর করে হোস্টের টানেল প্রযোজ্য হতে পারে বা নাও হতে পারে। bridged মোডে গেস্ট ভৌত LAN-এ সমমর্যাদার অংশ এবং হোস্টের টানেল অপ্রাসঙ্গিক। এই দুই মোড একই হোস্ট কনফিগারেশন থেকে বিপরীত উত্তর দেয়।

কিছু বদলানোর আগে মোডটি লিখে রাখুন, কারণ ফলাফল কী অর্থ বহন করতে পারে তা এটি নির্ধারণ করে।

এমন একটি অনুরোধ করুন যার গন্তব্য আপনি জানেন

এমন একটি সেবায় নিরীহ অনুরোধ পাঠান যা সে যে সোর্স ঠিকানা দেখেছে তা জানায়। তারপর সেই গন্তব্যের জন্য গেস্টের নিজের রাউটিং সিদ্ধান্ত দেখুন: ip route get 203.0.113.5 গেস্ট যে ইন্টারফেস ও গেটওয়ে ব্যবহার করবে তা ছাপে।

ইন্টারফেসটি যদি গেস্টের সাধারণ NIC হয়, তাহলে ট্রাফিক গেস্টের ভেতরের টানেল দিয়ে যাচ্ছে না।

দ্বিতীয় অ্যাডাপ্টার, প্রক্সি সেটিং বা গেস্ট-সাইড VPN ক্লায়েন্ট একটি অ্যাপ্লিকেশনের জন্য উত্তর বদলাতে পারে, অন্যটির জন্য নয়। আপনি যে অ্যাপ্লিকেশনটি সত্যিই গুরুত্ব দেন সেটিই পরীক্ষা করুন, শেল থেকে সাধারণ অনুরোধ নয়।

রিজলভার আলাদাভাবে যাচাই করুন

বদলে যাওয়া এক্সিট ঠিকানা বলে না কোন রিজলভার হোস্টনেমটি সামলেছে। প্ল্যাটফর্মের সাথে মেলে এমন টুল দিয়ে নামটি স্পষ্টভাবে জিজ্ঞাসা করুন, এবং কোন সার্ভার উত্তর দিল তা লক্ষ্য করুন। বিভক্ত DNS মানে রিজলভার প্রশ্ন ও রাউটিং প্রশ্নের উত্তর আলাদা।

এই দুটি যেকোনো দিকেই সরে যেতে পারে, এবং এই সরণ প্রায়ই প্রকৃত ত্রুটি।

systemd হোস্টে resolvectl query উত্তরের পেছনের ইন্টারফেস ও DNS সার্ভারের নাম দেয়। পুরোনো সেটআপ সার্ভারটি dig আউটপুটে দেখায় — যেভাবেই হোক উদ্দেশ্য হলো কোন সার্ভার উত্তর দিল তা দেখা, শুধু উত্তর এল কি না তা নয়।

ব্যর্থতার নীতি পরীক্ষা করুন, শুধু সফলতা নয়

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

টানেল পড়ে গেলে যে গেস্ট ভৌত NIC-এ ফিরে যায় সে ঠিক তাই করে যা NAT মোড অনুমোদন করে।

মোড ও পরিধি লিখে রাখুন

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

IPv4 যদি টানেল অনুসরণ করে, তা বলুন। দাবিটি IPv6, অন্য নেমস্পেস বা অন্য নেটওয়ার্কের অন্য VM-এ বাড়াবেন না।