OpenVPN রুট প্ল্যানে bypass-dhcp আসলে কী যোগ করে

redirect-gateway def1 bypass-dhcp থাকা একটি প্রোফাইল IPv4 ডিফল্ট ওভাররাইডের সঙ্গে একটি সংকীর্ণ ব্যতিক্রম মিলিয়ে দেয়। মানুষ শেষ শব্দটি পড়ে মোবাইল সংযোগের সাধারণ সমাধান আশা করে, তারপর এমন একটি DHCP তত্ত্বে দুপুর কাটায় যা ফ্ল্যাগটি কখনো সমর্থন করেনি। প্রতিটি অংশ একটি কাজ করে, আর ব্যতিক্রমটি তার সুনামের চেয়ে অনেক ছোট।

শুধু মোবাইল নেটওয়ার্কের ব্যর্থতাকে অ্যাড্রেস বরাদ্দের ওপর চাপানোর আগে ফ্ল্যাগগুলিকে আলাদা করুন। ওই স্ট্রিংয়ের দুই অর্ধের একটির সঙ্গে অন্যটির কোনো সম্পর্ক নেই।

দুই ফ্ল্যাগ, দুই অসম্পর্কিত কাজ

def1 দিয়ে ক্লায়েন্ট আগে থেকে থাকা ডিফল্টটি বদলানোর বদলে দুটি IPv4 অর্ধ-ডিফল্ট যোগ করে। 0.0.0.0/1 ঠিকানা-ক্ষেত্রের নিচের অর্ধেক ঢাকে এবং 128.0.0.0/1 উপরের অর্ধেক, তাই একসঙ্গে তারা প্রতিটি গন্তব্যে পৌঁছায়, অথচ প্রতিটি 0.0.0.0/0-এর চেয়ে বেশি নির্দিষ্ট থাকে। ফলে মূল ডিফল্টটি ওই লুকআপগুলি না জিতেও টেবিলে থাকে, যা পুরনো গেটওয়েকে ক্লায়েন্টের স্পষ্টভাবে রুট করা যেকোনো কিছুর জন্য পৌঁছনযোগ্য রাখে। এটি টেবিলে দুটি ওভারল্যাপিং ডিফল্টও রেখে যায়, তাই রুট ডাম্প প্রোফাইল যা ইঙ্গিত করে তার চেয়ে অদ্ভুত দেখাতে পারে।

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

এর অস্তিত্বের কারণ যান্ত্রিক। একবার অর্ধ-ডিফল্টগুলি বহির্গামী ট্রাফিক ধরে নিলে, ভৌত নেটওয়ার্কের একটি সার্ভারের দিকে করা DHCP নবায়ন টানেলের ভেতরে রুট হয়ে যেত, যদি না কিছু ওই ঠিকানাটিকে সত্যিকারের ইন্টারফেসে পিন করে দেয়। ফ্ল্যাগটি সেটিই করে।

ব্যতিক্রমটি আসলে কীসের মধ্যে সীমাবদ্ধ

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

ক্লায়েন্ট আসলে কী ইনস্টল করেছে তা যাচাই করুন

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

একই সঙ্গে VPN এন্ডপয়েন্টের রুটটি ব্যবহারযোগ্য রাখুন। এন্ডপয়েন্ট ব্যতিক্রমটি DHCP ব্যতিক্রমের চেয়ে আলাদা প্রয়োজন এবং তা ছাড়া টানেলটি যে ট্রান্সপোর্ট তাকে টিকিয়ে রাখে তাকেই ধরে ফেলতে পারে।

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

পথের বাকি অংশ এই ফ্ল্যাগে নেই

সার্ভারের এখনো ক্লায়েন্টের ইন্টারনেট ট্রাফিক ফরওয়ার্ড করার অনুমতি এবং তা ফেরত দিতে পারে এমন এগ্রেস ব্যবস্থা দরকার। ক্লায়েন্ট-সাইড কোনো রুট সার্ভারে অনুপস্থিত ফরওয়ার্ডিং বা সোর্স ট্রান্সলেশন তৈরি করে না, এবং কোনো ফ্ল্যাগ কাজ করা রিটার্ন পথের বিকল্প নয়।

নাম রিজলিউশন ও IPv6—দুটিরই নিজস্ব নীতি দরকার। IPv4 ওভাররাইড রিজলভারকে টানেল-সাইড সার্ভারের দিকে নির্দেশ করে না, IPv6 কভারেজও তৈরি করে না, আর যে ক্লায়েন্ট কেবল v4 রিডাইরেক্ট করে সে v6 পথটি অপরিবর্তিত রাখে।

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