Pi হটস্পট, Pi-hole ও VPN: প্রতিটি সেবাকে একটি কাজ দিন
একটি Pi-তে তিনটি সহায়ক চালু করার আগে ঠিক করুন DHCP, DNS ও প্যাকেট ফরওয়ার্ডিংয়ের মালিক কে। দ্বৈত মালিকানা প্রতিদ্বন্দ্বী লিজ ও রিজলভার লুপ তৈরি করে।
একটি ফোন Pi-এর হটস্পটে যোগ দেয়, ঠিকানা পায়, তবু পৃষ্ঠাটি ব্যর্থ হয়। Pi-তে একটি হটস্পট সহায়ক, Pi-hole ও একটি VPN ক্লায়েন্ট চলছে, এবং প্রত্যেকে মনে করে সে পথের একটি অংশের মালিক। এসব বিন্যাসের বেশিরভাগ ব্যর্থ হয় কোনো উপাদান নষ্ট বলে নয়, বরং কারণ দুটি উপাদান একই কাজ করে। যেকোনোটি টিউন করার আগে প্রতিটি ফাংশনের জন্য একজন মালিক নির্ধারণ করুন।
প্রতিটি ফাংশনের জন্য একজন মালিক নির্ধারণ করুন
এখানে চারটি ফাংশন গুরুত্বপূর্ণ, এবং প্রতিটির জন্য ঠিক একজন মালিক দরকার। নিচের তালিকাটি ফাংশন, একটি কার্যকর মালিক এবং দুটি সেবা একই দাবি করলে কী ভুল হয় তা দেখায়।
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
ওভারল্যাপ সাধারণত একবারে একটি প্যাকেজ করে আসে। হটস্পট সহায়ক নিজের dnsmasq ইনস্ট্যান্স ইনস্টল করে, Pi-hole 53 পোর্ট চায়, আর VPN ক্লায়েন্ট রুট যোগ করে। প্রতিটি ধাপ আলাদাভাবে যুক্তিসঙ্গত দেখায়, কিন্তু একসাথে তারা এমন একটি মেশিন তৈরি করে যেখানে দ্বিতীয় যে সেবাটি চালু হয়, সে প্রথমটির আচরণ নিঃশব্দে বদলে দেয়।
অন্য কিছু চালু করার আগে মালিকদের লিখে রাখুন। বিল্ড নোটে একটি ছোট তালিকা পরবর্তী কোনো ইনস্টলকে আগে থেকেই মালিক থাকা ফাংশন দখল করা থেকে বিরত রাখে।
একটি রেঞ্জ বেছে নিন এবং সেটি টানেল থেকে দূরে রাখুন
হটস্পট রেঞ্জ, তাতে Pi-এর ঠিকানা, DHCP পুল এবং ক্লায়েন্টরা যে রিজলভার পায় তা বেছে নিন। ওই রেঞ্জটি আপস্ট্রিম LAN ও VPN টানেল রেঞ্জ থেকে আলাদা রাখুন, কারণ ওভারল্যাপিং সাবনেট রাউটিং সমস্যাকে ঠিকানা অনুবাদের প্রকল্পে পরিণত করে। টানেলের সাথে ওভারল্যাপ করা রেঞ্জ Pi-কে দুটি অভিন্ন প্রিফিক্সের মধ্যে আকস্মিক রাউটার বানিয়ে দেয়। রেঞ্জ ও পুল ডিফল্টে ফেলে না রেখে হটস্পট কনফিগারেশনে লিখুন।
যদি NetworkManager-এর শেয়ারড মোড হটস্পটের মালিক হয়, DHCP সার্ভার যোগ করার আগে কার্যকর সংযোগটি পরীক্ষা করুন। শেয়ারড মোড নিজের সহায়ক চালু করে ও ফরওয়ার্ডিং সক্রিয় করে, তাই ওই ইন্টারফেসের ঠিকানা-পরিকল্পনার মালিক ইতিমধ্যে সে-ই। শুধু উপলব্ধ বলে দ্বিতীয় সার্ভার যোগ করলে অনুলিপি নয়, প্রতিদ্বন্দ্বী অফার তৈরি হয়।
IPv6 নিয়ে সচেতনভাবে সিদ্ধান্ত নিন। অনেক সেটআপে রাউটার বিজ্ঞাপন ও DHCPv6 DHCPv4-এর চেয়ে ভিন্ন সহায়ক থেকে আসে, আর VPN নীতি কেবল IPv4 কভার করলে IPv6 চালু রাখা ক্লায়েন্টদের টানেল এড়িয়ে যাওয়া পথ দেয়। হয় IPv6 দিকটি পরিকল্পনা করুন, নয়তো লিখিত কারণে হটস্পট ইন্টারফেসে এটি বন্ধ করুন।
53 পোর্টে আসলে কে উত্তর দেয়
কনফিগারেশন বদলানোর আগে 53 পোর্টে শোনা প্রতিটি প্রসেস তালিকাভুক্ত করুন। যে Pi-তে স্থানীয় রিজলভার স্টাব, Pi-hole ও একটি শেয়ারিং সহায়ক চলে, সেখানে শ্রোতার তালিকাই কে কোয়েরির উত্তর দেয় তার একমাত্র নির্ভরযোগ্য মানচিত্র:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole-এর ইন্টারফেস নির্দেশিকা ব্যাখ্যা করে যে একটি ইন্টারফেসে সীমিত রিসেপশন মোডও ওয়াইল্ডকার্ড সকেট ব্যবহার করে অন্যত্র আসা প্যাকেট বাতিল করতে পারে। এটি কেবল নির্বাচিত ইন্টারফেসে বাইন্ড করার সমান নয়, আর অন্য DNS সেবাকে মেশিন ভাগ করতে হলে ঠিক সেই বিন্যাসই উদ্দেশ্য।
দুটি প্রসেস সাধারণত একই ঠিকানা ও পোর্টে বাইন্ড করতে পারে না, যদিও SO_REUSEPORT শেয়ার্ড বাইন্ড সফল করতে পারে; তবুও একটি ওয়াইল্ডকার্ড শ্রোতা সংকীর্ণ সেবার জন্য আসা প্যাকেট নিতে পারে। আপনি যে ভূমিকা চান তার জন্য নথিভুক্ত মোড বেছে নিন এবং নির্ধারিত ক্রমে সেবাগুলো পুনরায় চালু করুন।
Pi-hole-এর প্রশাসনিক পৃষ্ঠা হটস্পট নেটওয়ার্কের বাইরে রাখুন। ক্লায়েন্টদের রিজলভার দরকার, ওয়েব ইন্টারফেস বা API নয় যা রিজলভারের কনফিগারেশন বদলাতে পারে।
দুটি DNS পা, প্রতিটির জন্য একটি নীতি
একটি ক্লায়েন্ট কোয়েরি ফোন থেকে Pi-তে যায়, আর আলাদা কোয়েরি Pi থেকে তার আপস্ট্রিম রিজলভারে যায়। ফরওয়ার্ড করা হটস্পট ট্র্যাফিকের সাথে মেলা রাউটিং নিয়ম দ্বিতীয় পায় স্বয়ংক্রিয়ভাবে প্রযোজ্য হয় না, কারণ Pi সেই ট্র্যাফিক স্থানীয়ভাবে তৈরি করে। VPN যদি DNS বহন করার কথা হয়, স্থানীয় পথের নিজস্ব নীতি দরকার।
লুপ থেকে সাবধান। Pi-hole-এর আপস্ট্রিমকে Pi নিজে সরবরাহ করা ঠিকানায় নির্দেশ করা, সরাসরি বা পোর্ট-ফরওয়ার্ডের মাধ্যমে, এমন কোয়েরি তৈরি করে যা সময় শেষ হওয়া পর্যন্ত ঘুরতে থাকে। এটিকে সত্যিকারের আপস্ট্রিম দিন, বা যে ডোমেইনগুলোর উত্তর দিতে পারে না সেগুলোর জন্য শর্তসাপেক্ষ ফরওয়ার্ডার দিন।
টানেল পড়ে গেলে কী হবে তা ঠিক করুন। স্থানীয় রিজলভারে ফিরে যাওয়া ব্রাউজিং চালু রাখে কিন্তু VPN-এর বাইরে নাম ফাঁস করতে পারে; ব্লক করা নীতি অক্ষত রাখে এবং বিভ্রাটকে দৃশ্যমান ত্রুটিতে পরিণত করে। যেকোনো পছন্দই যুক্তিসঙ্গত, তবে তা ডিফল্ট থেকে উত্তরাধিকার নয়, বেছে নিতে হবে।
পথ ও বিভ্রাটের আচরণ প্রমাণ করুন
স্তরে স্তরে পরীক্ষা করুন: ক্লায়েন্ট ঠিকানা পায়, ক্লায়েন্ট Pi-এর মাধ্যমে নাম রিজলভ করে, Pi নির্ধারিত আপস্ট্রিমের মাধ্যমে রিজলভ করে, এবং একটি অ্যাপ্লিকেশন অনুরোধ সম্পন্ন করে। সফল ping DNS সম্পর্কে কিছুই বলে না, আর সফল লুকআপ ফরওয়ার্ডিং সম্পর্কে কিছুই বলে না।
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1তারপর টানেল বন্ধ করুন এবং পুনরাবৃত্তি করুন। নির্ধারিত আচরণ কয়েক সেকেন্ডের মধ্যে দেখা উচিত, Pi-hole বা হটস্পট সেবার হাতে করা রিস্টার্টের পরে নয়। বিভ্রাটের সময় ক্লায়েন্টের রিজলভার সেটিং পরীক্ষা করুন, কারণ একটি গৌণ পাবলিক রিজলভার নীতি ব্যর্থতা প্রত্যাশা করলেও উত্তর দিতে থাকবে।
ফরওয়ার্ডিং ও NAT-এর জন্য একজন মালিক রাখুন এবং তা Pi নিজে থেকে নয়, একটি ক্লায়েন্ট থেকে যাচাই করুন। যে অনুরোধ Pi সফলভাবে ছাড়ে, ফেরার পথে তা তবুও ফেলে দেওয়া হতে পারে, এবং ক্লায়েন্টই একমাত্র জায়গা যেখানে পুরো পথটি দৃশ্যমান।