গেস্ট VPN ও হোস্ট VPN: কোন রুটটি আসলে জেতে

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

প্রথমে গেস্টের সংযুক্তি লিখে রাখুন

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

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

গেস্টের এন্ডপয়েন্ট বাইরের দিকে অনুসরণ করুন

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

যে কোনো প্রসঙ্গে একটি বিস্তৃত রুট অন্য ক্লায়েন্টের প্রত্যাশিত ট্র্যাফিক ধরে নেয়। গেস্টের ভিতরে 0.0.0.0/0 রুট আর পূর্ণ-টানেল হোস্ট ক্লায়েন্ট—দুটোই সবকিছুর দাবি করে, আর শেষে যে প্রযোজ্য হয় সে-ই জেতে। গেস্টের ভার্চুয়াল নেটওয়ার্ক, স্থানীয় LAN ও দূরবর্তী নেটওয়ার্কের মধ্যে ওভারল্যাপ প্রাইভেট প্রিফিক্সে একই ফল দেয়, ব্যর্থতাগুলো প্রমাণীকরণ সমস্যার মতো দেখায়; ঠিকানা অনুবাদের আচরণ কন্টেইনার নেটওয়ার্কিং-এর জন্য বর্ণিত একই আচরণ।

আগে ও পরের রেকর্ড তুলনা করুন

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

রিস্টার্টের পরেও মালিকানা স্পষ্ট রাখুন

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

কোন পক্ষ ডিফল্ট রুটের মালিক তা ঠিক করুন এবং তা রানবুকে লিখুন। গেস্টের রিস্টার্ট বা হোস্টের নেটওয়ার্ক বদল যা নিঃশব্দে মালিকানা উল্টে দেয়, তা এমন VPN নিয়ে বাগ রিপোর্ট তৈরি করে যা কখনো দোষী ছিল না। ব্যবস্থাটি রিবুটের পরেও টিকে থাকা উচিত, কেউ কেন এটি কাজ করেছিল তা না মনে রেখেই।