গেটওয়েতে OpenVPN DNS: dnsmasq ও ফায়ারওয়ালের পরিধি

টানেল ঠিকানায় dnsmasq চালান, শুধু ক্লায়েন্ট পুল থেকে DNS অনুমোদন করুন, রিজলভার পুশ করুন, তারপর সরাসরি কোয়েরি আর অ্যাপের নিজের লুকআপ পরীক্ষা করুন।

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

লিসেনার দুই দিকের একটি স্থানীয় সেবা

ভেতরের দিকে ক্লায়েন্ট গেটওয়ের টানেল ঠিকানায় 53 নম্বর পোর্টে একটি কোয়েরি পাঠায়। বাইরের দিকে ডিমন সেই কোয়েরি তার কনফিগার করা আপস্ট্রিমে পাঠিয়ে দেয়। দুই অর্ধেকই কাজ করতে হবে, আর তারা ভিন্নভাবে ব্যর্থ হয়।

ক্লায়েন্ট যে টাইমআউট জানায় আর গেটওয়েতে যে টাইমআউট দেখা যায়, তারা একই ত্রুটি নয়।

টানেল ঠিকানা বাঁধুন, সব ঠিকানা নয়

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic আলাদা আলাদা ঠিকানা বাঁধে এবং tun0 পরে আবির্ভূত হলে তা সামলায়, যা এমন হোস্টে গুরুত্বপূর্ণ যেখানে VPN সেবা পুনরায় চালু হয়। loopback তালিকাভুক্ত করলে পাবলিক লিসেনার যোগ না করেই স্থানীয় টুলগুলো কাজ করে। no-resolv ডিমনকে হোস্টের রিজলভার কনফিগারেশন থেকে আপস্ট্রিম উত্তরাধিকার করতে বাধা দেয়, আর no-hosts এই ইনস্ট্যান্সকে গেটওয়ের hosts ফাইল প্রকাশ করা থেকে বিরত রাখে। এই অপশনগুলোর কোনোটিই কাউকে সেবাটি কোয়েরি করার অনুমতি দেয় না।

দ্বিতীয় ডিমন চালু করার আগে 53 নম্বর পোর্টে বিদ্যমান লিসেনার আছে কি না দেখুন, আর ভুল ডিরেক্টরির এলোমেলো ফাইলের বদলে ডিস্ট্রিবিউশনের কনফিগারেশন মালিক ব্যবহার করুন।

DNS ইনপুট অনুমোদন করুন, টানেল ট্রানজিট নয়

যে ফায়ারওয়াল নিয়মগুলো এটি কাজ করায় সেগুলো স্থানীয়-ইনপুট নিয়ম, টানেল ইন্টারফেস, ক্লায়েন্ট পুল, গেটওয়ে ঠিকানা আর 53 নম্বর পোর্টে সীমিত। প্রতি প্রোটোকলে একটি করে, দুইটি নিয়মই যথেষ্ট:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP ছাড়াও TCP-এর উপরেও চলে, তাই শুধু UDP নিয়ম বড় উত্তরগুলোকে এমনভাবে ব্যর্থ করে যা মাঝে মাঝে ঘটে বলে মনে হয়। এগুলো ufw route অনুমতি নয়, এবং সেগুলো tun0 -এ বিস্তৃত অনুমোদনে পরিণত হওয়া উচিত নয়। বিষয়বস্তুর মতোই ক্রমও সমান গুরুত্বপূর্ণ: আগে থাকা যে নিয়ম সব ইনপুট tun0 থেকে ফেলে দেয়, সেটিই জিতে যায়, আর চূড়ান্ত ড্রপের নিচে অনুমোদন যোগ করলে কিছুই তৈরি হয় না।

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

আপস্ট্রিম অর্ধেকটি আলাদা পথ

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

উত্তরগুলো কাজ করানোর জন্য সীমাহীন টানেল আউটপুট যোগ করবেন না; ট্র্যাক করা উত্তরগুলোর তা দরকার নেই।

অপশনটি পুশ করুন, তারপর হ্যান্ডঅফ পরীক্ষা করুন

সার্ভার পুশ করা অপশন দিয়ে ক্লায়েন্টদের কাছে রিজলভার ঘোষণা করতে পারে। এটি একটি অপশন, কোনো নির্দেশ নয় যা অপারেটিং সিস্টেমকে মানতেই হবে:

push "dhcp-option DNS 10.90.0.1"

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

ক্লায়েন্টের রিজলভার কনফিগারেশনের জন্য এক মালিকই লক্ষ্য, আর পুশ সাধারণত সেই মালিক হয় কেবল তখনই যখন ক্লায়েন্ট প্ল্যাটফর্ম সম্মত হয়।

আপনি আসলে যা বানিয়েছেন তা পরীক্ষা করুন

একটি ব্যক্তিগত সম্পূর্ণ যোগ্য নাম আর একটি অনুমোদিত বহির্ভূত নাম সরাসরি টানেল ঠিকানার বিরুদ্ধে UDP আর TCP উভয়ে কোয়েরি করুন। তারপর অ্যাপের সাধারণ লুকআপ পথে পুনরাবৃত্তি করুন।

যদি সরাসরি কোয়েরি কাজ করে কিন্তু অ্যাপ এখনও ব্যর্থ হয়, ত্রুটি সার্ভারে নয়, হ্যান্ডঅফে:

  • ক্লায়েন্ট কখনোই পুশ করা অপশনটি প্রয়োগ করেনি।
  • পরে আরেকটি রিজলভার সেট হয় আর প্রতিযোগিতায় জিতে যায়।
  • অ্যাপটি তার নিজের রিজলভার লাইব্রেরি বা ক্যাশে করা উত্তর ব্যবহার করে।

শেষে নিশ্চিত করুন যে অনুমোদিত VPN পথের বাইরের কোনো উৎস লিসেনার আদৌ ব্যবহার করতে পারে না। সফল রিজলিউশন যে ঠিকানা ফিরিয়েছে তাতে অনুমোদন দেয় না, তাই এই দুই প্রশ্ন আলাদা রাখুন।

সম্পর্কিত নিবন্ধ