কীভাবে একটি IPv4 গন্তব্যকে OpenVPN টানেলের বাইরে পাঠাবেন

বেশিরভাগ ফুল-টানেল সেটআপ প্রতিটি প্যাকেট VPN-এর মধ্য দিয়ে পাঠায়, এবং redirect-gateway নির্দেশিকাই তা করে। একটি একক গন্তব্যকে তবুও ছাড় দেওয়া যায়। ওই ঠিকানার জন্য net_gateway প্লেসহোল্ডারসহ একটি হোস্ট রুট যোগ করলে ক্লায়েন্টকে বলা হয় যেন মেশিনের মূল গেটওয়ে দিয়ে সেখানে পৌঁছায়, আর বাকি সবকিছু টানেল ব্যবহার করতেই থাকে।

লাইনটি ক্ষতিকর দেখায় এবং প্রায়শই তাই হয়, কিন্তু এটি কেবল একটি প্রশ্নের মীমাংসা করে: ওই নির্দিষ্ট IPv4 ঠিকানার প্যাকেটগুলো কোথায় যায়। এটি DNS, IPv6, ফায়ারওয়াল নীতি বা কোন প্রক্রিয়া সংযোগটি খুলেছে তা বদলায় না, এবং এর প্রত্যেকটিই ছাড়টি নীরবে ব্যর্থ করতে পারে।

net_gateway আসলে কী বোঝায়

ওই ছাড়ের প্রোফাইল এন্ট্রি এক লাইন: route 198.51.100.77 255.255.255.255 net_gateway। প্রথম ঠিকানাটি গন্তব্যের জন্য একটি ডকুমেন্টেশন প্লেসহোল্ডার, মাস্কটি এটিকে একক-হোস্ট রুট করে, এবং শেষ টোকেনটি গেটওয়ে প্লেসহোল্ডারের নাম দেয়। OpenVPN রুট ইনস্টল করার সময় গেটওয়ে প্লেসহোল্ডারগুলো সমাধান করে। vpn_gateway মানে টানেলের নিজের গেটওয়ে, অর্থাৎ VPN লিংকের দূরবর্তী প্রান্ত। net_gateway মানে VPN কিছু বদলানোর আগে হোস্টের যে ডিফল্ট গেটওয়ে ছিল, যা সাধারণত ভৌত নেটওয়ার্কের স্থানীয় রাউটার।

তৃতীয় একটি প্লেসহোল্ডার, remote_host, VPN সার্ভারের ঠিকানা বোঝায়, এবং এটি আছে যাতে টানেল ভৌত পথে সার্ভারে পৌঁছাতে পারে। এই তিনটিকে গুলিয়ে ফেলা হলো একটি ছাড় ভুল জায়গায় যাওয়ার বা একেবারেই ইনস্টল না হওয়ার সবচেয়ে সাধারণ কারণ।

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

কেন একটি হোস্ট রুট টানেলের ডিফল্টকে হারিয়ে দেয়

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

255.255.255.255 মাস্কসহ একটি ঠিকানার রুট হলো /32, এবং IPv4 যতটা নির্দিষ্ট হতে পারে ততটাই এটি। ওই ঠিকানার প্যাকেট মূল্যায়ন করার সময় /32 মিলে যায় এবং কোন রুট আগে ইনস্টল হয়েছিল তা নির্বিশেষে জিতে যায়। এটিই ছাড়টির পেছনের প্রক্রিয়া, এবং রুটটি সত্যিই উপস্থিত থাকলে Linux, macOS ও Windows-এ এটি একইভাবে কাজ করে।

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

ছাড়টি যা ঢেকে না

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

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

অ্যাপ্লিকেশন পরিসর হলো তৃতীয়টি। নিয়মটি গন্তব্য-ভিত্তিক, তাই ওই ঠিকানায় সংযোগ করা প্রতিটি প্রক্রিয়া সরাসরি পথ ব্যবহার করে, আপনার মনে থাকা প্রক্রিয়াটি হোক বা না হোক। বিপরীতভাবে, একটি ওয়েবসাইট একাধিক ঠিকানা থেকে উত্তর দিতে পারে, তাই একটি /32 ছাড় দিলে সাইটটিকে ছাড় দেওয়া হয় না। যদি প্রকৃত প্রয়োজন প্রতি-অ্যাপ্লিকেশন রাউটিং হয়, তাহলে Community ক্লায়েন্টের রুট টেবিল ভুল হাতিয়ার।

নিজেকে বোকা না বানিয়ে ছাড়টি যাচাই করা

ব্রাউজার দিয়ে নয়, ইনস্টল করা রুট দিয়ে শুরু করুন। Linux-এ কার্নেলকে জিজ্ঞাসা করুন নির্দিষ্ট ঠিকানার জন্য কোন রুট ও পরবর্তী হপ ব্যবহার করবে; Windows-এ ওই /32-এর জন্য রুট টেবিল পড়ুন। নিশ্চিত করুন গেটওয়েটি ভৌত, টানেল নয়। এন্ট্রিটি না থাকলে প্রোফাইলটি প্রয়োগ হয়নি বা ক্লায়েন্টের রুট বদলানোর অনুমতি ছিল না।

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

শেষে, রুটকে অগ্রাহ্য করতে পারে এমন নিয়ন্ত্রণগুলো দেখুন। ক্লায়েন্ট-সাইড kill switch বা Windows-এর block-outside-dns সেটিং সরাসরি ট্রাফিক নিষিদ্ধ করতে পারে, যা রুট সঠিক থাকা সত্ত্বেও ব্যর্থ সংযোগ হিসেবে দেখা যায়। ছাড়টি কাজ করছে দেখাতে ওই নিয়ন্ত্রণগুলো বন্ধ করবেন না; নীতি যদি সরাসরি পথ নিষিদ্ধ করে, তবে ছাড়টি VPN সেবার মালিকের জন্য একটি নকশা সমস্যা।

পুনরায় সংযোগ বা নেটওয়ার্ক বদলানোর পরে আবার যাচাই করুন, কারণ VPN-পূর্ববর্তী গেটওয়ে ও উপলব্ধ পথ প্রোফাইলের নয়, মুহূর্তের বৈশিষ্ট্য।