WireGuard DNS DNAT: جواب کا راستہ فعال رکھیں

WireGuard کلائنٹ کی DNS استفسار کو دوسرے resolver کی طرف موڑنا ایک قاعدے جیسا لگتا ہے مگر تین فیصلوں کی طرح برتاؤ کرتا ہے۔ منزل دوبارہ لکھنی ہوگی، پیکٹ آگے بھیجنا ہوگا، اور جواب کو گیٹ وے کے بنائے ہوئے ترجمے کی حالت سے گزر کر واپسی کا راستہ ملنا ہوگا۔ تیسرا چھوڑ دیں تو استفسار صاف نکل جاتا ہے جبکہ کلائنٹ ہمیشہ انتظار کرتا رہتا ہے۔

10.77.0.0/24 میں مجاز کلائنٹ wg0 کے ذریعے آتے ہیں، اعلان شدہ پتہ 10.77.0.1 پوچھتے ہیں اور 203.0.113.53 پر resolver درکار ہوتا ہے — یہ مثال لیں۔ اوپر والا پتہ دستاویزات کے لیے جگہ دار ہے، فعال سروس نہیں۔

استفسار کو موڑنے سے صرف اس کی منزل بدلتی ہے

PREROUTING میں منزل-NAT قاعدہ راستہ بندی کے فیصلے سے پہلے پتہ دوبارہ لکھتا ہے، اس لیے پیکٹ بعد میں پرانی منزل کی بجائے نئی منزل کی طرف روٹ ہوتا ہے۔ کلائنٹ کا ماخذ پتہ اس عمل سے اچھوتا رہتا ہے۔ اسی لیے مکمل دکھنے والا قاعدہ بھی خاموشی پیدا کر سکتا ہے: درخواست اب ایسے resolver کی طرف جاتی ہے جس نے کلائنٹ کی نجی رینج کے بارے میں کبھی نہیں سنا۔ گیٹ وے نے ایک فیلڈ کا ترجمہ کیا اور دوسرا مسئلہ وراثت میں پایا۔

دونوں 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

جواب کا راستہ الگ فیصلہ ہے

دو ترتیبیں جواب کی واپسی کی اجازت دیتی ہیں، اور کسی ایک کو جلدی چننا ایک ڈیبگ سیشن بچاتا ہے۔ یا تو اوپر والے resolver کے پاس اس گیٹ وے سے 10.77.0.0/24 تک واپسی کا راستہ ہے، یا گیٹ وے اخراج پر ماخذ کا ترجمہ کرتا ہے تاکہ جواب ایسے پتے پر پہنچے جو اوپر والا پہلے سے جانتا ہے۔ دونوں کام کرتے ہیں؛ اوپر والے پر آپ کے کنٹرول سے صرف ایک مطابقت رکھتا ہے۔

راستہ بندی پہلی کوشش کی حقدار ہے، کیونکہ یہ کلائنٹ کا پتہ resolver کے لیے نظر آتا رکھتی ہے اور ترجمے کی دوسری تہہ سے بچتی ہے۔ جب اوپر والا آپ کے کنٹرول سے باہر ہو، تو مخصوص اخراجی انٹرفیس پر ماخذ کا ترجمہ عملی انتخاب ہے۔

اس ترجمے کو موڑنے جتنا ہی سختی سے محدود رکھیں، ورنہ قاعدہ ہر اس چیز کے لیے عام مقصد کا 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

کنکشن ٹریکنگ نقشے کو جوڑے میں رکھتی ہے، اس لیے واپسی پر جواب کلائنٹ کے اصل tuple میں دوبارہ لکھا جاتا ہے۔ اخراجی قاعدے کے بغیر resolver اپنا جواب ایسے نجی پتے پر بھیجتا ہے جہاں پہنچ نہیں سکتا، اور کلائنٹ غلطی کی بجائے وقت ختم ہونا دیکھتا ہے۔

قواعد کام کے دکھنے سے زیادہ تنگ لکھیں

آگے بھیجنے کی اجازت اسی دائرے کی ہے۔ مشین پر ہر DNAT کنکشن قبول کرنے کی بجائے کلائنٹ سے resolver تک بہاؤ اور وہ واپسی ٹریفک اجازت دیں جسے conntrack پہلے ہی پہچانتا ہے۔ جامع اجازت ان پورٹ فارورڈنگز کو بھی اختیار دیتی ہے جن کا DNS سے کوئی تعلق نہیں۔

گیٹ وے کا اپنا resolver الگ کوڈ راستہ ہے۔ مقامی طور پر جاری استفسار OUTPUT سے گزرتی ہے، اس لیے گیٹ وے شیل سے جانچ نہ PREROUTING قاعدے کی مشق کرتی ہے نہ آگے بھیجنے کی پالیسی کی۔ اسی لیے مقامی جانچ کامیاب ہو سکتی ہے جبکہ ہر کلائنٹ ناکام ہو، اور اس کا الٹ بھی اتنا ہی عام ہے۔

یہاں کچھ بھی پورٹ 443 پر HTTPS کے اوپر DNS یا پورٹ 853 پر TLS کے اوپر DNS کا احاطہ نہیں کرتا، اور کچھ بھی IPv6 کا احاطہ نہیں کرتا۔ IPv6 resolver کے ساتھ ترتیب دیا گیا کلائنٹ پورے انتظام کو خوشی سے نظر انداز کر دے گا۔

نیا استفسار کیا ثابت کرتا ہے

کنکشن ٹریکنگ پچھلے نقشے یاد رکھتی ہے، اس لیے قاعدے کی تبدیلی سے پہلے بھیجی گئی استفسار پرانی حالت سے جواب پا سکتی ہے اور نئے قاعدے کو ٹوٹا ہوا دکھا سکتی ہے۔ نئے ماخذ پورٹ سے شروع کریں اور، جہاں کلائنٹ جوابات کیش کرتا ہے، نئے نام سے۔

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

پہلا حکم دکھاتا ہے کہ کلائنٹ کا راستہ بالکل حل ہوتا ہے یا نہیں، اور دوسرا وہ ترجمہ دکھاتا ہے جو گیٹ وے نے واقعی نصب کیا، tuple کی دونوں سمتیں شامل کر کے۔ صحیح resolver کی طرف اشارہ کرنے والا مگر جواب کا شمار کنندہ صفر پر اٹکا ہوا نقشہ فلٹر کا مسئلہ نہیں، واپسی راستے کا مسئلہ ہے۔

کچھ بھی موڑنے سے پہلے تصدیق کریں کہ resolver وہ نام جانتا ہے جن کی آپ توقع کرتے ہیں۔ ایسا متبادل جو عوامی ناموں کا جواب دیتا ہے مگر آپ کے نجی زون کا نہیں ایک کارآمد تلاش کو NXDOMAIN میں بدل دیتا ہے جو ٹوٹی سرنگ جیسا لگتا ہے۔ کلائنٹ راستہ شامل ہونے سے پہلے گیٹ وے سے براہ راست resolver جانچیں۔ اور iptables ایکسٹینشنز کا حوالہ اس DNAT اور masquerade معنویت کی دستاویز کرتا ہے جس پر یہ قواعد منحصر ہیں۔