কেন OpenVPN ক্লায়েন্ট ব্লক নিয়ম কখনো FORWARD-এ পৌঁছায় না
ক্লায়েন্ট-থেকে-ক্লায়েন্ট ট্রাফিক OpenVPN প্রক্রিয়ার ভেতরেই থাকতে পারে এবং হোস্টের FORWARD চেইন কখনো পার না করতে পারে, তাই শূন্য কাউন্টার কিছুই প্রমাণ করে না।
একই OpenVPN সার্ভারে থাকা দুটি ক্লায়েন্ট তাদের পুলের জন্য DROP নিয়ম যোগ করার পরেও একে অপরের কাছে পৌঁছাতে পারে। নিয়মটি FORWARD চেইনে বসে আছে, ট্রাফিক স্পষ্টভাবেই প্রবাহিত হচ্ছে, আর সেই নিয়মের কাউন্টার শূন্যেই থাকে। স্বাভাবিক সিদ্ধান্ত হলো ফায়ারওয়াল ভাঙা। কিন্তু বেশিরভাগ সময় প্যাকেটটি চেইনে একেবারেই ঢোকেনি।
OpenVPN সার্ভার হয়ে একটি পিয়ার প্যাকেট দুটি পথে যেতে পারে, আর সেগুলো নির্ধারিত হয় কনফিগারেশন দ্বারা, ফায়ারওয়াল দ্বারা নয়। কোন পথ ব্যবহৃত হচ্ছে তা জানলে বোঝা যায় হোস্ট নিয়মটি আদৌ সঠিক জায়গায় আছে কি না।
একটি পিয়ার প্যাকেট যে দুটি পথে যেতে পারে
অভ্যন্তরীণ ফরওয়ার্ডিং অপশন নিষ্ক্রিয় থাকলে ক্লায়েন্ট A থেকে আসা প্যাকেট টানেল ইন্টারফেসে পৌঁছায় এবং গন্তব্য থাকে ক্লায়েন্ট B-এর বরাদ্দকৃত ঠিকানার ভেতরে। সার্ভারের রাউটিং টেবিল এটি একই টানেল ইন্টারফেস দিয়েই ফেরত পাঠায়, কারণ B-এর ঠিকানার রুট সার্ভারের নিজের। এটি হোস্টের ভেতর দিয়ে ঢোকা-বেরোনোর প্রবাহ, এবং IPv4 ফরওয়ার্ডিং পথই এটি মূল্যায়ন করে।
অভ্যন্তরীণ ফরওয়ার্ডিং অপশন সক্রিয় থাকলে সার্ভার প্রক্রিয়া প্যাকেটটিকে একটি সংযুক্ত ক্লায়েন্টের সঙ্গে মিলিয়ে দেয় এবং নিজেই সেই ক্লায়েন্টের কাছে ফেরত লেখে। প্যাকেটটি ডেমন-এর ভেতরে হ্যান্ডল হয় এবং কখনো টানেল ডিভাইসে পুনরায় ঢোকে না, তাই হোস্টের ফরওয়ার্ডিং পথ সম্পূর্ণ বাদ পড়ে। OpenVPN 2.6 ম্যানুয়াল এই অপশনকে অভ্যন্তরীণ ক্লায়েন্ট-থেকে-ক্লায়েন্ট ফরওয়ার্ডিং বলে বর্ণনা করে, আর ঠিক এ কারণেই হোস্ট ফায়ারওয়ালের নিয়ম এটি দেখতে পায় না।
এমন ডিপ্লয়মেন্টেও তৃতীয় এক ধরন আছে যেগুলো ডেটা চ্যানেলকে কার্নেল মডিউলে অফলোড করে। ফরওয়ার্ডিং সিদ্ধান্ত ও এনক্রিপশন ইউজারস্পেস থেকে সরে যায়, আর netfilter প্রবাহটি দেখে কি না তা নির্ভর করে অফলোড পথটি কীভাবে তৈরি তার ওপর। কখনো ধরে নেবেন না যে পুরনো নিয়মসেট অফলোড করা সার্ভারে ইউজারস্পেসের মতোই আচরণ করবে। প্যাকেজ সংস্করণ থেকে নয়, চলমান কনফিগারেশন থেকেই মোড নিশ্চিত করুন।
যখন কাউন্টার কখনো নড়ে না
শূন্য কাউন্টার মানে প্যাকেটটি সেই বিন্দুতে ওই নিয়মের সঙ্গে মেলেনি, এবং এর কয়েকটি কারণ আছে। প্রথমটি হলো ওপরের বাইপাস: ট্রাফিক চেইনে পৌঁছায়ইনি। দ্বিতীয়টি হলো ইন্টারফেস, দিক, উৎস বা গন্তব্যে অমিল, যা সাধারণত ঘটে যখন পুল পুনঃসংখ্যায়িত হয় আর নিয়ম এখনো পুরনো প্রিফিক্সের নাম ধরে রাখে।
তৃতীয়টি অবস্থান। চেইনের আগের কোনো নিয়ম আপনার DROP মূল্যায়নের আগেই প্রবাহটি গ্রহণ করতে পারে, আর পরের কোনো নিয়মই হতে পারে যা ফলাফল সত্যিই নির্ধারণ করে। কাউন্টার দৃশ্যমান রেখে চেইনটি ক্রমে পড়ুন, তারপর পরীক্ষা পুনরাবৃত্তি করলে কোন নিয়মের গণনা বাড়ে তা দেখুন।
দুটি ক্লায়েন্টের মধ্যে একটি নিয়ন্ত্রিত বিনিময় চালান, যাদের প্রকৃত ঠিকানা আপনি সার্ভারের নিজস্ব অবস্থা থেকে নিশ্চিত করেছেন, মনে থাকা কোনো লিজ থেকে নয়। সংশ্লিষ্ট কাউন্টারটি এখনো না নড়লে মিলটি পুনর্লিখনের আগে পথটিকে সন্দেহ করুন। এটি নড়লে কিন্তু সংযোগ এখনো সফল হলে, ড্রপটি পরে ওভাররাইড হচ্ছে এবং সমস্যা ক্রমে। ওই উত্তরই ঠিক করে মেরামতটি নিয়ম পরিবর্তন না টোপোলজি পরিবর্তন, তাই কিছু সম্পাদনার আগেই তা জেনে নিন।
এমন সীমা বাছাই করা যা ফিল্টার করতে পারে
নীতিকে যদি হোস্ট ফায়ারওয়ালেই থাকতে হয়, তবে ট্রাফিককে সেখানে রাখুন যেখানে ফায়ারওয়াল তা দেখতে পারে। অভ্যন্তরীণ ফরওয়ার্ডিং নিষ্ক্রিয় করাই সমর্থিত উপায় যাতে পিয়ার ট্রাফিক টানেল ইন্টারফেস ও ফরওয়ার্ডিং পথ পেরোয়, এর বিনিময়ে প্রতিটি পিয়ার প্যাকেট হোস্ট স্ট্যাকের মধ্য দিয়ে পাঠাতে হয়।
তারপর প্রবাহটি নিখুঁতভাবে মিলান। ট্রাফিক উভয় দিকেই টানেল ইন্টারফেসে আসে এবং টানেল ইন্টারফেস দিয়েই বেরোয়, তাই যে নিয়ম কেবল ভৌত ইন্টারফেস বিবেচনা করে সেগুলো মিলবে না। ঠিকানাভিত্তিক নিয়মের চলমান পুল দরকার, আর সেগুলোকে ফেরতের দিকটিও হিসাবে নিতে হবে, যেমনটা সামনের দিকটি।
অনেক ডিপ্লয়মেন্টের জন্য ক্লায়েন্ট বা গ্রুপ স্তরে ফিল্টার করাই ভালো, যেখানে পরিচয় জানা থাকে এবং নীতি পুনঃসংযোগে বদলে যাওয়া ঠিকানার বদলে ব্যবহারকারীকে অনুসরণ করে। এটি হোস্ট চেইনের থেকে আলাদা প্রক্রিয়া, আর স্পষ্ট কারণ ছাড়া দুটো মেশানো উচিত নয়।
মাইগ্রেশনের সময় পুরনো টোপোলজির নিয়মসেট অপরিবর্তিত পার করবেন না। ঠিকানা পুল, ইন্টারফেসের নাম আর ফরওয়ার্ডিং মোড—সবই ঠিক করে একটি নিয়ম মেলে কি না, আর আগে কাজ করা কপি করা নিয়ম হলো সবচেয়ে বিভ্রান্তিকর প্রমাণ। যে প্রবাহটির অনুমতি দিতে চান সেখান থেকেই শুরু করুন এবং তার সঙ্গে মেলা নিয়মটি লিখুন।
নিয়মে ভরসা না করে বিচ্ছিন্নতা পরীক্ষা করা
নিষিদ্ধ ক্ষেত্রটি আর অনুমোদিত ক্ষেত্রটি একই রানে পরীক্ষা করুন। এক ক্লায়েন্ট থেকে অন্যটির দিকে নতুন সংযোগ শুরু করুন এবং তা ব্যর্থ হয় কি না নিশ্চিত করুন, তারপর যেটির অনুমতি থাকা উচিত সেই সংযোগটি এখনো কাজ করে কি না নিশ্চিত করুন। কেবল প্রথমটি পরীক্ষা করলে সবকিছু আটকানো ফায়ারওয়ালকেও সফল মনে হয়।
সার্ভার কনফিগারেশন পুনরায় লোড করার পর এবং কোনো ক্লায়েন্ট পুনঃসংযুক্ত হওয়ার পর পুনরাবৃত্তি করুন, কারণ অভ্যন্তরীণ ফরওয়ার্ডিং ও পুল বরাদ্দ রানটাইম অবস্থা। উভয় দিকে কাউন্টার দেখুন, কারণ যে নিয়ম এক দিক মেলে কিন্তু উত্তরটি মেলে না তা আংশিক বিচ্ছিন্নতা তৈরি করে যা দ্রুত পরীক্ষায় ধরা কঠিন।
বিচ্ছিন্নতা হলো সেই সীমায় পর্যবেক্ষিত ফলাফল যা সত্যিই প্রবাহ বহন করে। হোস্টের কোথাও একটি DROP নিয়ম প্রমাণ নয়; ব্যর্থ সংযোগ আর তা ঘটানো নিয়মের নড়ে ওঠা কাউন্টারই প্রমাণ।