OpenWrt পলিসি রাউটিং: যে চেইন লোকাল DNS ধরে

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

দুটি ফ্লো, একটি রিজলভার ঠিকানা

প্রথম ফ্লোটি মানুষ যা কল্পনা করে। একটি ক্লায়েন্ট রাউটারের রিজলভারকে জিজ্ঞাসা করে, রিজলভারটি উপরমুখে ফরোয়ার্ড করে, আর সেই ফরোয়ার্ডেড প্যাকেট বেরোনোর পথে রাউটার পার হয়। সেই প্যাকেট ফরোয়ার্ডেড ট্রাফিক দেখছে এমন যেকোনো কিছুর কাছে দৃশ্যমান।

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

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

ফরোয়ার্ডেড ও লোকালি তৈরি প্যাকেট ভিন্নভাবে ঢোকে

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

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

এটি প্যাকেট কোথায় জন্মায় তার বৈশিষ্ট্য, কোনো নির্দিষ্ট প্যাকেজের নয়। একটি চেইনের জন্য লেখা নিয়মের অন্যটি সম্পর্কে সহজভাবে কোনো মত নেই। কোনো পরিমাণ নিয়ম টিউনিং এটি বদলায় না।

আউটপুট চেইন বেছে নিন, তারপর ম্যাচ সংকুচিত করুন

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

তারপর নিয়মটি কী মেলায় তা সংকুচিত করুন। রিজলভার যে পোর্টটি সত্যিই ব্যবহার করে সেই পোর্টে গন্তব্য রিজলভার ঠিকানা, রাউটার যা তৈরি করে সবকিছু টানেলে পাঠানোর চেয়ে অনেক ছোট সিদ্ধান্ত।

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

টানেলের নিজের ট্রান্সপোর্ট নিয়মের বাইরে রাখুন

টানেলের বাইরের সংযোগও রাউটার তৈরি করে। যে নিয়ম লোকালি তৈরি সব ট্রাফিক টানেলে পাঠায় তা টানেলকে নিজের ভেতর দিয়ে রাউট করবে, আর এটি আদৌ উঠবে না।

ব্যবস্থাপনা প্রবেশ দ্বিতীয় ক্ষতি। রাউটার থেকে উৎপন্ন প্রশাসনিক সেশন, বা সেগুলির উত্তর, অতি-প্রশস্ত লোকাল নিয়মে টানেলে টেনে নেওয়া হতে পারে এবং LAN থেকে অপ্রাপ্য হয়ে যেতে পারে।

টানেলের শেষ বিন্দুটি ম্যাচ থেকে বাদ দিন, আর নিয়মটি রিজলভার ঠিকানায় সীমাবদ্ধ রাখুন। এটি DNS প্রয়োজনের জন্য যথেষ্ট আর বিবেচনার জন্য যথেষ্ট ছোট।

দুটি জনগোষ্ঠীই পরীক্ষা করুন, একটি নয়

রাউটার নিজের কোয়েরি করছে দেখুন আর কোন ইন্টারফেস এটি বহন করেছে লিখে রাখুন। LAN হোস্ট থেকে লুকআপটি আবার করুন আর সেটি যে পথ নিয়েছে লিখে রাখুন। পলিসি নিয়মের কাউন্টার দুটি উত্তরই অনুমান ছাড়াই দৃশ্যমান করে।

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

পোর্টটিও পরীক্ষা করুন: গন্তব্য পোর্ট 53 মেলানো নিয়ম 853-এ DNS over TLS বা HTTPS শেষ বিন্দু দিয়ে পৌঁছানো রিজলভার মিস করে। কনফিগার করা আপস্ট্রিম সত্যিই যে ট্রান্সপোর্ট ব্যবহার করে তা মেলান, আর লিকটি সঠিক কারণে বন্ধ হয়।