Pi-hole VPN সংযোগের পরেও বিজ্ঞাপন ব্লক করছে না: পাঁচটি যাচাই

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

1. ক্লায়েন্ট আসলে যে রিজলভার ব্যবহার করছে তা পড়ুন

রাউটারকে নয়, ক্লায়েন্টকে জিজ্ঞাসা করুন। Linux-এ resolvectl status প্রতি লিঙ্কের DNS সার্ভার এবং কোন লিঙ্ক জিতছে তা দেখায়; একা /etc/resolv.conf সাধারণত 127.0.0.53-এ ইশারা করা একটি স্টাব। Windows-এ ipconfig /all প্রতি অ্যাডাপ্টারের DHCP-প্রদত্ত সার্ভার তালিকাভুক্ত করে, আর macOS-এ scutil --dns স্কোপ অনুযায়ী একই জিনিস দেখায়। উত্তরটি যদি Pi-hole-এর ঠিকানা না হয়, তাহলে আপনার অ্যাসাইনমেন্ট সমস্যা আছে এবং ধাপ 2 হলো তার জায়গা।

সিস্টেম রিজলভার সঠিকভাবে সেট থাকলেও দুটি জিনিস তাকে হারিয়ে দেয়। নিজস্ব সিকিউর DNS আছে এমন ব্রাউজার (Chrome-এর “Use secure DNS”, Firefox-এর network.trr.mode) HTTPS-এর মাধ্যমে পাবলিক রিজলভারে কোয়েরি পাঠায় এবং পোর্ট 53 কখনও খোলে না। আর ক্লায়েন্টের ভেতরের VPN ক্লায়েন্ট তার টানেল ইন্টারফেসে ~. রাউটিং ডোমেইনসহ একটি DNS সার্ভার ইনস্টল করতে পারে, যা ওই লিঙ্ককে প্রতিটি নামের জন্য কর্তৃত্বপূর্ণ করে তোলে।

অ্যাপ্লিকেশন যে পথ নেয় তা পরীক্ষা করুন, ডিবাগ টুল যে পথ নেয় তা নয়। resolvectl query example.com দেখায় কোন লিঙ্ক উত্তর দিয়েছে, আর getent hosts example.com অ্যাপ্লিকেশনের মতো একই NSS পথ দিয়ে যায়; macOS-এ dscacheutil -q host -a name example.com scutil --dns যে স্কোপড রিজলভার তালিকাভুক্ত করে তা পড়ে। খালি dig এটি করে না: এটি /etc/resolv.conf পড়ে এবং প্রতি-লিঙ্ক নির্বাচন এড়িয়ে যায়, তাই প্রতিটি অ্যাপ্লিকেশন পুশ করা রিজলভার ব্যবহার করলেও এটি Pi-hole থেকে উত্তর দিতে পারে, আর এটিই সেই নির্দিষ্ট ব্যর্থতা যার জন্য এই তালিকাটি আছে। একটি নির্দিষ্ট সার্ভার পরীক্ষা করতে dig @192.168.1.53 রাখুন।

2. কে উত্তর দিচ্ছে তা নিশ্চিত করুন

অ্যাসাইনমেন্ট আসে যেকোনো কিছু থেকে যা DHCP-এর উত্তর দেয়। dnsmasq-এ এটি একটি লাইন, dhcp-option=6,192.168.1.53; রাউটারের ওয়েব UI-তে এটি LAN DHCP অংশের DNS ফিল্ড। ক্লায়েন্টদের এটি দেখতে হলে রিনিউ করতে হবে। দিনের পর দিন চালু থাকা ডিভাইস এখনও পুরোনো লিজ ধরে রাখে, আর হাতে লেখা রিজলভারওয়ালা ডিভাইস তা চিরকাল ধরে রাখে। প্রচার ধরে নেওয়ার বদলে একটি পরীক্ষা ক্লায়েন্টে রিনিউ করুন।

IPv6 হলো সেই অর্ধেক যা বাদ পড়ে। রাউটার বিজ্ঞাপন নিজের DNS সার্ভার বহন করতে পারে (RDNSS), আর OpenWrt-এ সেটি odhcpd-এর ra_dns অপশন; যে ক্লায়েন্ট IPv6 পছন্দ করে সে ওই সার্ভার ব্যবহার করে, অথচ আপনি এইমাত্র সেট করা DHCPv4 অপশনটি অব্যবহৃত পড়ে থাকে। IPv6 DNS পরিবেশন করতে প্রস্তুত না থাকলে শুধু DNS বিজ্ঞাপনটি মুছুন: odhcpd-এ ra_dns, বা রাউটার বিজ্ঞাপনের উত্তর দেয় এমন যেকোনো কিছুর RDNSS অপশন। পুরো বিজ্ঞাপন বন্ধ করলে LAN থেকে IPv6 অ্যাড্রেসিংও চলে যায়, যা আপনি যে পরিবর্তন করতে চেয়েছিলেন তার চেয়ে অনেক বড়, কিন্তু শুধু DNS অপশন মুছলে অ্যাড্রেসিং অক্ষত থাকে এবং অনুপস্থিত RDNSS প্যাকেট ক্যাপচারে দৃশ্যমান হয়।

3. প্রমাণ করুন কোয়েরি Pi-hole-এ পৌঁছায়

Pi থেকে একটি কোয়েরি নেটওয়ার্ক পথ সম্পর্কে কিছুই প্রমাণ করে না। এটি ক্লায়েন্ট থেকে চালান এবং প্রতিক্রিয়া কোড পড়ুন:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

টাইমআউট ফিল্টারিং বা রুটকে ইশারা করে; REFUSED অ্যাক্সেস নিয়মকে ইশারা করে; SERVFAIL Pi-hole-এর পেছনের আপস্ট্রিম রিজলভারকে ইশারা করে; কোয়েরি লগে কখনও না আসা সঠিক উত্তর মানে ক্লায়েন্ট অন্য কিছু জিজ্ঞাসা করেছে। UDP ও TCP 53 পরীক্ষা করুন, কারণ বড় উত্তর ও কিছু রিজলভার TCP-তে ফিরে যায়, আর Pi-hole কনটেইনারে চললে দুটিই প্রকাশ করুন। শুধু UDP ঢাকা ম্যাপিং মাঝে মাঝে ব্যর্থতা তৈরি করে যা প্যাকেট লসের মতো দেখায়।

এরপর Pi-hole-এর লিসেনিং মোড ঠিক করে সে আদৌ উত্তর দেবে কি না। শুধু-লোকাল মোডে dnsmasq সরাসরি সংযুক্ত সাবনেটে নেই এমন উৎসের কোয়েরি উপেক্ষা করে, আর অন্য রাউটারের পেছনের বা টানেল দিয়ে আসা ক্লায়েন্ট ঠিক এমনই দেখায়: ক্লায়েন্ট টাইমআউট হয় আর কোয়েরি কখনও লগে পৌঁছায় না। যে কোয়েরি REFUSED হিসেবে দেখা যায় তা বরং অ্যাক্সেস লিস্ট বা ফায়ারওয়াল নিয়মে প্রত্যাখ্যাত হয়েছে। সব উৎস অনুমোদন করাই স্বাভাবিক সমাধান, সঙ্গে একটি ফায়ারওয়াল নিয়ম যা পোর্ট 53 আপনার নিজের সাবনেটে সীমিত রাখে।

4. টানেল উত্তরটি প্রতিস্থাপন করেছে নাকি গিলে ফেলেছে তা যাচাই করুন

এই সেই কেস যেখানে দুটি উপসর্গই লুকিয়ে থাকে। রাউটার নিজেই VPN ক্লায়েন্ট হলে, পুশ করা DNS অপশন টানেল ওঠার মুহূর্তেই LAN সেটিংকে অগ্রাহ্য করতে পারে: OpenVPN সার্ভার dhcp-option DNS পুশ করে, আর WireGuard প্রোফাইল নিজের DNS এন্ট্রি বহন করে। টানেল চালু থাকা অবস্থায় রাউটারের কার্যকর রিজলভার পড়ুন, তার আগে নয়, আর LAN পেজ যা দাবি করে তা উপেক্ষা করুন।

অন্য ত্রুটিটি প্রতিস্থাপন নয়, পৌঁছানোযোগ্যতা। টানেলের অনুমোদিত প্রিফিক্সে আপনার LAN সাবনেট থাকলে, রাউটারের একটি রুট আছে যা 192.168.1.53-এর কোয়েরি টানেলে পাঠায়, আর ওপাশে ফেরার কোনো রুট নেই: টানেল সুস্থ থাকলেও কোয়েরি টাইমআউট হয়। উল্টোটা ঘটে যখন Pi-hole এমন সাবনেটে থাকে যা টানেল বহন করে না। আবার DNS-এ হাত দেওয়ার আগে ঠিকানাটি টানেলের অনুমোদিত প্রিফিক্স ও রাউটারের রুট টেবিলের সঙ্গে মিলিয়ে নিন।

দুটো নয়, একটি সমাধান বাছুন। হয় টানেলকে DNS থেকে দূরে রাখুন — OpenVPN-এ pull-filter ignore “dhcp-option DNS” এবং WireGuard-এ AllowedIPs-এ কোনো LAN প্রিফিক্স ছাড়া — নয়তো পুশ করা রিজলভার মেনে নিয়ে ওই রাউটারের পেছনের ক্লায়েন্টদের জন্য স্থানীয় ফিল্টারিং ছেড়ে দিন। যেটাই বাছুন, প্রোফাইলের পাশে লিখে রাখুন, কারণ পরের যে ব্যক্তি এটি সম্পাদনা করবেন তিনি অন্যথায় দুর্ঘটনাক্রমে সিদ্ধান্তটি উল্টে দেবেন।

5. পুনঃসংযোগের পর পরীক্ষাটি আবার করুন

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

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