WireGuard DNS DNAT: উত্তর পথ চালু রাখুন

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

10.77.0.0/24-এ অনুমোদিত ক্লায়েন্টরা wg0 দিয়ে আসছে, বিজ্ঞাপিত ঠিকানা 10.77.0.1 জিজ্ঞাসা করছে এবং 203.0.113.53-এ একটি রিজলভার দরকার—এই উদাহরণটি ধরুন। আপস্ট্রিম ঠিকানাটি একটি ডকুমেন্টেশন স্থানধারক, কার্যকর সেবা নয়।

প্রশ্ন পুনর্নির্দেশ করলে কেবল তার গন্তব্য বদলায়

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

উভয় DNS পরিবহনের জন্য মিলে যাওয়া নিয়ম দরকার, কারণ উত্তর কেটে গেলে ক্লায়েন্ট TCP-তে ফিরে যায়।

নিচের নিয়মগুলি একটি আগত ইন্টারফেস, একটি ক্লায়েন্ট রেঞ্জ এবং একটি মূল গন্তব্য ঠিকানা নির্বাচন করে। গেটওয়েতে অন্য কিছু প্রভাবিত হয় না, আর গেটওয়ে নিজেই যে প্রশ্ন পাঠায় তা আদৌ মেলে না।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

উত্তর পথ একটি পৃথক সিদ্ধান্ত

দুটি বিন্যাসে উত্তর ফিরে আসতে পারে, এবং আগেভাগে একটি বেছে নিলে একটি ডিবাগিং সেশন বাঁচে। হয় আপস্ট্রিম রিজলভারের এই গেটওয়ে দিয়ে 10.77.0.0/24-এ ফেরার রুট আছে, নয়তো গেটওয়ে ইগ্রেসে উৎস অনুবাদ করে যাতে উত্তরটি এমন ঠিকানায় পৌঁছায় যা আপস্ট্রিম আগেই জানে। দুটোই কাজ করে; কেবল একটি আপস্ট্রিমের ওপর আপনার নিয়ন্ত্রণের সঙ্গে মেলে।

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

সেই অনুবাদকে পুনর্নির্দেশের মতোই সংকীর্ণ রাখুন, নইলে নিয়মটি যেকোনো মিলে যাওয়া জিনিসের জন্য সাধারণ-উদ্দেশ্যের NAT হয়ে যাবে:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

কাজটি যতটা দেখায় তার চেয়ে সংকীর্ণ নিয়ম লিখুন

ফরওয়ার্ডিং অনুমতি একই পরিধির। বক্সের প্রতিটি DNAT সংযোগ গ্রহণ করার বদলে ক্লায়েন্ট-থেকে-রিজলভার প্রবাহ এবং conntrack ইতিমধ্যে চেনে এমন ফিরতি ট্র্যাফিকের অনুমতি দিন। সার্বিক গ্রহণযোগ্যতা এমন পোর্ট ফরওয়ার্ডও অনুমোদন করে যেগুলোর DNS-এর সঙ্গে কোনো সম্পর্ক নেই।

গেটওয়ের নিজস্ব রিজলভার আলাদা কোড পথ। স্থানীয়ভাবে জারি করা প্রশ্ন OUTPUT দিয়ে যায়, তাই গেটওয়ে শেল থেকে পরীক্ষা করলে PREROUTING নিয়ম বা ফরওয়ার্ডিং নীতি কোনোটিই অনুশীলন হয় না। এজন্যই স্থানীয় পরীক্ষা পাস করতে পারে অথচ প্রতিটি ক্লায়েন্ট ব্যর্থ হয়, আর উল্টোটাও সমান সাধারণ।

এখানে কিছুই পোর্ট 443-এ HTTPS-এর ওপর DNS বা পোর্ট 853-এ TLS-এর ওপর DNS কভার করে না, এবং IPv6-ও কভার করে না। IPv6 রিজলভার কনফিগার করা ক্লায়েন্ট পুরো ব্যবস্থাটি সানন্দে উপেক্ষা করবে।

নতুন প্রশ্ন কী প্রমাণ করে

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

কিছু পুনর্নির্দেশ করার আগে নিশ্চিত করুন রিজলভার আপনার প্রত্যাশিত নামগুলি জানে। এমন প্রতিস্থাপন যা পাবলিক নামের উত্তর দেয় কিন্তু আপনার ব্যক্তিগত জোনের নয় একটি কার্যকর লুকআপকে NXDOMAIN-এ পরিণত করে যা ভাঙা টানেলের মতো দেখায়। ক্লায়েন্ট পথ জড়িত হওয়ার আগে গেটওয়ে থেকে সরাসরি রিজলভার পরীক্ষা করুন। আর iptables এক্সটেনশন রেফারেন্স সেই DNAT ও masquerade শব্দার্থ নথিভুক্ত করে যার ওপর এই নিয়মগুলি নির্ভর করে।