OpenVPN ক্লায়েন্টদের Cloudflare দিয়ে রুট করবেন? আগে ভূমিকা যাচাই করুন

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

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

একই হোস্টে দুটি সেবা ট্রানজিট পথ নয়

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

তাই ডিজাইনের প্রশ্নটি সক্ষমতার প্রশ্ন। হয় ইনস্টল করা পণ্যটির অন্য নেটওয়ার্কের ট্রাফিক ফরওয়ার্ড করার নথিভুক্ত ভূমিকা আছে, নয়তো ট্রানজিট ফাংশনটি সম্পূর্ণ ভিন্ন জায়গার।

Cloudflare-এর কোন ভূমিকা ফরওয়ার্ড করতে পারে

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

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

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

বাইরের টানেলকে নতুন রুট থেকে স্বাধীন রাখুন

নতুন ইন্টারফেসের দিকে ডিফল্ট রুট যোগ করার মুহূর্তেই সার্ভারের নিজের আউটবাউন্ড ট্রাফিক তার জন্য প্রতিযোগিতা শুরু করে, আর এর মধ্যে OpenVPN ক্লায়েন্টদের উত্তর ও বক্সে আপনার SSH সেশনও পড়ে। সাধারণ উপসর্গ হলো একটি টানেল যা প্রতিষ্ঠিত হয়ে তারপর মরে যায়, বা একজন প্রশাসক বাইরে লক হয়ে যান যখন মনে হয় পরিবর্তনটি কাজ করেছে। এন্ডপয়েন্টের জন্য ip route get আগে ও পরে তুলনা করুন, এবং সার্ভারের নিজের ট্রান্সপোর্ট যেখানে ছিল সেখানেই রাখতে পলিসি রাউটিং বা হোস্ট রুট ব্যবহার করুন। এই তুলনাটি বক্স থেকেই চালান, কারণ সার্ভারের নিজের রুট সম্পর্কে নিজের দৃষ্টিভঙ্গিই আসল।

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

ফরওয়ার্ডিং ও অনুবাদকে এক ফ্লোতে সীমাবদ্ধ করুন

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

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

আপনি যে চারটি উত্তরে পৌঁছেছেন এবং প্রতিটি যা প্রমাণ করে সেই পর্যবেক্ষণ লিখে রাখুন। যে ট্রানজিট পথের বর্ণনা দিতে পারেন, সেটিই পরের ঘটনা পর্যালোচনায় আপনি রক্ষা করতে পারবেন।