কেন রাউটারের নিজস্ব DNS VPN টানেল এড়িয়ে যায়?

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

প্যাকেট ক্যাপচারটি আসলে কোন প্রবাহের

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

সেই দ্বিতীয় কোয়েরির উৎস রাউটার নিজেই এবং গন্তব্যও সে নিজেই, আর প্ল্যাটফর্ম তার পথ বেছে নেয় অন্য কনফিগারেশন ব্লক থেকে। দুটি বিনিময়ই একই নাম বহন করে, এবং কোনোটিই অন্যটির অনুলিপি নয়। তাই LAN পাশে নেওয়া ক্যাপচার প্রমাণ করে ক্লায়েন্টের প্যাকেট কোথায় গেছে, কিন্তু বাইরে যাওয়া প্যাকেট সম্পর্কে কিছুই বলে না।

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

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

সকেট তালিকায় loopback বা LAN ঠিকানায় বাঁধা লিসেনার দেখালে রাউটার অন্য হোস্টে ফরওয়ার্ড না করে স্থানীয়ভাবেই উত্তর দিচ্ছে। তখন ক্যাপচার দেখায় যে ফলস্বরূপ আপস্ট্রিম কোয়েরি টানেল ইন্টারফেস দিয়ে বেরোয় নাকি WAN দিয়ে, আর এটাই সেই উত্তর যা পলিসি রুট নিয়ম কখনো দিত না।

কেন পলিসি রুট দ্বিতীয় কোয়েরি কখনো দেখে না

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

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

pfSense রিজলভার কোথায় নিজের আপস্ট্রিম পথ ঠিক করে

pfSense এই বিভাজনটি দৃশ্যমান করে। ক্লায়েন্ট ট্র্যাফিক পলিসি রুটের মাধ্যমে VPN গেটওয়ে দিয়ে যেতে পারে, অথচ ফায়ারওয়ালের নিজের ট্র্যাফিক LAN নিয়ম নয়, রিজলভারের আউটগোয়িং সেটিং অনুসরণ করে। ওয়েব ইন্টারফেসে সেই সেটিংটি থাকে Services > DNS Resolver > Outgoing Network Interfaces-এর অধীনে, আর এর মান হলো রিজলভার আপস্ট্রিম কোয়েরির জন্য যে ইন্টারফেসগুলো ব্যবহার করতে পারে তার তালিকা।

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

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

সেটিংয়ের আগে ব্যর্থতার আচরণ বেছে নিন

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

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

দুটি ঘটনা সিদ্ধান্তটিকে জটিল করে। ব্যক্তিগত নামের জন্য এমন অভ্যন্তরীণ রিজলভার দরকার হতে পারে যা টানেল পৌঁছাতে পারে, আর নিজস্ব এনক্রিপ্টেড DNS থাকা ব্রাউজার বা অ্যাপ্লিকেশন রাউটারকে সম্পূর্ণ এড়িয়ে যেতে পারে, তাই আপনি যে রিজলভার কনফিগার করেছেন তা সবসময় প্রদত্ত অ্যাপের ব্যবহৃত রিজলভার নয়।

দুই পথ পরীক্ষা করুন এবং ফলাফল আলাদা রাখুন

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

LAN ক্লায়েন্ট থেকে রাউটারকে প্রথমে একটি পাবলিক নাম জিজ্ঞাসা করুন, তারপর একটি প্রাইভেট নাম যা কেবল আপনার অভ্যন্তরীণ জোনের উত্তর দেওয়া উচিত। কেবল দ্বিতীয় কোয়েরিতে ব্যর্থতা টানেল নয়, নাম ফরওয়ার্ডিংয়ের দিকে ইঙ্গিত করে:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

তারপর টানেল নামিয়ে দুই কোয়েরি পুনরাবৃত্তি করুন। প্রত্যাখ্যাত উত্তর মানে রিজলভার ব্যর্থতায় বন্ধ; সফল উত্তর মানে ফলব্যাক রিজলভার এবং তার ব্যবহৃত পথ। এটিকে আপনার লেখা নোট এবং একই মিনিটে WAN ইন্টারফেসে নেওয়া ক্যাপচারের সঙ্গে তুলনা করুন।

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