OpenVPN ক্লায়েন্টদের অন্য হোস্টের Pi-hole রিজলভারের দিকে পাঠান

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

ধাক্কা দেওয়া DNS অপশন কী করে এবং কী করে না

সার্ভার নিচের নির্দেশ দিয়ে একটি রিজলভার ঘোষণা করে, ধরে নিয়ে যে 192.168.50.53 Pi-hole হোস্ট। ক্লায়েন্ট অপশনটি পায় এবং, তার প্ল্যাটফর্ম ও রিজলভার ইন্টিগ্রেশন অনুযায়ী, তা টানেল ইন্টারফেসে প্রয়োগ করে বা স্থানীয় স্টাবের পক্ষে উপেক্ষা করে। রুট লাইন DNS লাইনের মতোই গুরুত্বপূর্ণ, কারণ যে রিজলভারে ক্লায়েন্ট পৌঁছায় না তা কোনো রিজলভারই নয়। এর কিছুই সার্ভারের দিক থেকে দেখা যায় না।

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

অপশন পাওয়া তা ব্যবহার করার সমান নয়। রিজলভার ম্যানেজারযুক্ত Linux ক্লায়েন্ট ধাক্কা দেওয়া সার্ভার গ্রহণ করে কেবল নির্দিষ্ট ডোমেইন পাঠাতে পারে; যে ক্লায়েন্ট নিজেই DNS সামলায় সে সেটিং পুরোপুরি বদলে দিতে পারে। ধাক্কা দেওয়া রুট কিছু প্ল্যাটফর্মে সীমিতও, যা অপশন গৃহীত হলেও রিজলভারকে অপ্রাপ্য রাখে। ক্লায়েন্টে দেখুন কোন সার্ভার উত্তর দেয়, সার্ভারে নয় কী পাঠানো হয়েছে।

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

Pi-hole থেকে পুলে ফেরার পথ

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

LAN রাউটারকে পুলের জন্য স্ট্যাটিক রুট দিন যেখানে OpenVPN গেটওয়ে পরের হপ, অথবা Pi-hole-এ ফরওয়ার্ড করার আগে গেটওয়েতে উৎস অনুবাদ করুন। প্রথমটি প্রতিটি ক্লায়েন্টের ঠিকানা Pi-hole-এর কোয়েরি লগে দৃশ্যমান রাখে। দ্বিতীয়টি ফেরার রুটের শর্ত সরায় কিন্তু প্রতিটি কোয়েরিকে গেটওয়ে থেকে আসা দেখায়। কোনোটিই ভুল নয়; তারা আলাদা প্রশ্নের উত্তর দেয়।

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

রাউট করা ক্লায়েন্টদের জন্য Pi-hole-এর শোনার মোড

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

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

প্রথম কোয়েরি কাজ করার জন্য সব উৎসের জন্য রিকার্শন খোলা ভুল মেরামত। এটি ব্যক্তিগত রিজলভারকে খোলা বানিয়ে দেয়, আর সংশোধন সীমিত অনুমতি, বৈশ্বিক নয়।

উত্তরকে কোয়েরি লগের সঙ্গে মিলান

ক্লায়েন্টকে জিজ্ঞাসা করুন, তারপর সার্ভার পরীক্ষা করুন এবং দুটির তুলনা করুন। systemd-resolved ক্লায়েন্টে নিচের কমান্ডগুলো জানায় কোন রিজলভার উত্তর তৈরি করেছে এবং প্রতি লিঙ্কে কোন সার্ভার কনফিগার করা আছে। এমন নাম ব্যবহার করুন যা কেবল Pi-hole জানে, কারণ Pi-hole-এর ঠিকানায় সরাসরি কোয়েরি পৌঁছানো প্রমাণ করে, কনফিগারেশন নয়।

resolvectl query intranet.example.lan
resolvectl dns

প্রত্যাশিত উত্তর 192.168.50.53-কে সার্ভার হিসেবে নাম দেয় এবং এমন ঠিকানা ফেরত দেয় যা কেবল সেই রিজলভারই জানত। তারপর Pi-hole-এর নিজের দৃশ্য দেখুন: pihole -t কোয়েরি লগ সরাসরি অনুসরণ করে, এবং প্রতিটি লাইন উৎস ঠিকানা বহন করে। উৎস যদি ক্লায়েন্টের টানেল ঠিকানা হয় তবে পুলের রুট অটুট। যদি এটি গেটওয়ের LAN ঠিকানা হয় তবে উৎস অনুবাদ চলছে এবং ক্লায়েন্টের নিজের ঠিকানা কখনো দেখা যাবে না।

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

গেটওয়ের ফরওয়ার্ডিং নিয়ম পরীক্ষা করুন

গেটওয়েকে ক্লায়েন্টের DNS প্যাকেট Pi-hole-এর দিকে ফরওয়ার্ড করতে হয়, আর যে নিয়ম এটি করে তা অনুমান না করে পড়া উচিত। নিচের কমান্ডগুলো পোর্ট 53 স্পর্শ করে এমন নিয়ম কাউন্টারসহ তালিকাভুক্ত করে, nftables হোস্টে এবং iptables হোস্টে। বিদ্যমান নিয়ম যদি শূন্য মিল দেখায়, তা সংকেত যে ট্রাফিক অনুবাদের আগেই ফেলে দেওয়া হচ্ছে।

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

হোস্ট যে সরঞ্জামই ব্যবহার করুক, পরীক্ষা সংকীর্ণ রাখুন: পুল উৎস হিসেবে, পোর্ট 53 গন্তব্য হিসেবে এবং Pi-hole একমাত্র অনুমোদিত লক্ষ্য হিসেবে। প্রশস্ত ফরওয়ার্ডিং নিয়ম যা পোর্ট 80-ও অনুমতি দেয়, তা আরেকটি সমস্যা যা ঘটার অপেক্ষায়।