DNS রিডাইরেক্টের পরে dnsmasq কোয়েরি কেন VPN এড়িয়ে যায়

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

মার্ক কোয়েরির সঙ্গে ভ্রমণ করে না

প্যাকেট মার্ক conntrack এন্ট্রিতে এবং উড়ন্ত প্যাকেটে থাকে। একটি REDIRECT নিয়ম সেই উড্ডয়ন শেষ করে: পেলোড একটি লোকাল সকেটে হস্তান্তরিত হয়, এবং মূল এন্ট্রি তার কাজ শেষ করেছে। এরপর রাউটার যা ছাড়ে তা হলো রিজলভার প্রসেসের তৈরি একটি নতুন সকেট, যার সোর্স রাউটারের নিজের ঠিকানা।

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

দুটি কথোপকথন সত্যিই একটি নাম ও একটি সময় ভাগ করে, আর এটাই ক্যাপচার দ্রুত দেখলে তাদের এক ফ্লো-এর মতো করে তোলে।

কোথায় ফরওয়ার্ডিং লোকাল রিজলিউশনে পরিণত হয়

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

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

রিজলভারকে তার নিজের ইগ্রেস পলিসি দিন

ডোমেইন-নির্দিষ্ট আপস্ট্রিম সবচেয়ে পরিষ্কার হাতিয়ার যখন কেবল কিছু নামের টানেল দরকার। dnsmasq একটি ডোমেইনে সীমিত server লাইন গ্রহণ করে, সাথে ঐচ্ছিক ইন্টারফেস বা সোর্স ঠিকানা যা কোয়েরিকে নির্বাচিত ডিভাইস থেকে বের করে দেয়। এই নির্দেশনাই দ্বিতীয় কথোপকথনকে VPN অনুসরণ করায়।

server=/corp.example/10.30.0.53@tun_work
log-queries

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

লাইনটি তৈরি করা ফাইলে নয়, রাউটার যে কনফিগারেশন মালিক সমর্থন করে সেখানে রাখুন, নইলে পরের রিলোড সমাধানটি মুছে দেবে।

একটি শেয়ার্ড ক্যাশ কী সংরক্ষণ করতে পারে না

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

ক্যাশ করা উত্তরও নতুন পথ সম্পর্কে প্রমাণ নয়। উত্তর মেমরি থেকে আসতে পারে, অথচ আপস্ট্রিম রুট ভাঙা থাকে।

পোর্ট 53-এর নিয়ম DNS over HTTPS বা TLS-এ কথা বলা অ্যাপ্লিকেশন সম্পর্কে কিছুই বলে না। সেই কোয়েরিগুলো কখনো রিডাইরেক্টে পৌঁছায় না, তাই শুধু পোর্ট 53-এর ওপর গড়া পলিসি ট্রাফিকের একটি উপসেটের বর্ণনা দেয় এবং উপসেট হিসেবেই নথিভুক্ত হওয়া উচিত।

প্রথম নয়, দ্বিতীয় কথোপকথন যাচাই করুন

আপনার নিয়ন্ত্রণে থাকা একটি নাম দিয়ে পরীক্ষা করুন এবং দুই দিক দেখুন। ক্লায়েন্ট-সাইড ক্যাপচার প্রমাণ করে কোয়েরি LAN ছেড়েছে; কেবল রাউটার দিকই প্রমাণ করে এরপর তা কোথায় গেছে।

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

প্রতিটি চেষ্টার আগে ক্যাশ ফ্লাশ করুন, কারণ উষ্ণ উত্তর ভাঙা আপস্ট্রিম লুকায়। TCP-তে পুনরাবৃত্তি করুন, তারপর টানেল বন্ধ করে পুনরাবৃত্তি করুন যাতে দেখেন রিজলভার তার পছন্দের পথ হারালে কী করে। সেই শেষ আচরণই ঠিক করে ডিজাইনটি fail-closed না কেবল ভাগ্যবান।