WireGuard ڈی این ایس پش نہیں کرتا: نجی BIND زون کی خدمت

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

ٹنل اور ریزالور الگ الگ معاہدے ہیں

WireGuard جان بوجھ کر چھوٹا ہے۔ یہ آپ کے درج کردہ پتوں کے لیے پیکٹ منتقل کرتا ہے اور پیرز کی تصدیق کرتا ہے؛ اس پرت کے اوپر سب کچھ آپ کا ڈیزائن ہے۔ OpenVPN dhcp-option DNS پش کر سکتا ہے کیونکہ اس کا کنٹرول چینل ترتیب لے کر جاتا ہے، اور یہی فرق دونوں کے درمیان آنے جانے والوں کو ٹھوکر مارتا ہے۔

لہٰذا کام کرنے والا ٹنل نام حل ہونے کے بارے میں کچھ نہیں بتاتا۔ کلائنٹ کے پاس 10.90.0.1 تک بہترین راستہ ہو سکتا ہے اور وہ پھر بھی اپنی استفسارات عوامی ریزالور کو بھیج سکتا ہے، اسی لیے علامت “VPN نے DNS توڑ دیا” جیسی لگتی ہے، جبکہ DNS کبھی VPN کی طرف نہیں تھا۔

زون کی خدمت بغیر تکرار ریزالور بنے کریں

سرور کی طرف ایک چھوٹا مستند زون ہے، عام ریزالور نہیں۔ اس مثال میں گیٹ وے 10.90.0.1 ہے، کلائنٹ 10.90.0.0/24 ہیں، اور جس ایپلیکیشن کی آپ کو فکر ہے وہ 10.60.0.20 پر جواب دیتی ہے۔

دوسرا بلاک بنانے کے بجائے یہ سیٹنگز موجودہ options بلاک میں ضم کریں:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

پھر زون اور اس کی فائل کا اعلان کریں:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

دوبارہ لوڈ کرنے سے پہلے تصدیق کریں، کیونکہ لوڈ کے وقت نحوی خرابی ہر اس زون کے لیے پورا سرور گرا دیتی ہے جس کی وہ خدمت کرتا ہے:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP اور TCP 53 صرف VPN انٹرفیس پر کھولیں۔ عوامی انٹرفیس پر نجی اختیار شائع کرنا استفسارات اور گنتی دونوں کو دعوت دیتا ہے، اور allow-transfer بند ہی رہنا چاہیے جب تک کسی ثانوی کو واقعی ضرورت نہ ہو۔

کلائنٹ کو اس کی طرف موڑیں، ہر لنک کے لیے

فرض کریں کہ کنکشن NetworkManager کی ملکیت ہے اور ریزالور systemd-resolved ہے۔ پہلے موجودہ پالیسی پڑھیں، خاص طور پر کوئی جڑ روٹنگ ڈومین، کیونکہ ~. اندراج اس سے آگے نکل جائے گا جو آپ شامل کرنے جا رہے ہیں۔

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

ٹلڈ اہم حرف ہے۔ یہ ڈومین کو صرف-راستہ کے طور پر نشان زد کرتا ہے: corp.example کے تحت نام اس لنک کے DNS سرور پر جاتے ہیں، اور ڈومین مختصر نام کی تلاش کے لاحقے کے طور پر شامل نہیں ہوتا۔ اس کے بغیر، portal ٹائپ کرنے پر portal.corp.example حل ہونا شروع ہو جاتا ہے، جو آپ کے لیے سہولت اور باقی سب کے لیے حیرت ہے۔ ٹلڈ کو اقتباس کے اندر رکھیں، کیونکہ بغیر اقتباس والا ایک شیل توسیع ہے جو آپ کی ہوم ڈائریکٹری کی طرف اشارہ کرنے کا منتظر ہے۔

تبدیلی انٹرفیس کے مالک مینیجر کے ذریعے لاگو کریں، پھر کنکشن دوبارہ جوڑیں۔ اسی انٹرفیس کے لیے دوسری wg-quick مثال شروع نہ کریں؛ دو مالک راستوں پر لڑیں گے اور ان میں سے ایک بدترین لمحے میں جیتے گا۔

نام سے پہلے راستہ جانچیں

کلائنٹ سے نام پوچھیں اور جواب نیز اسے بنانے والے سرور دونوں کی تصدیق کریں:

resolvectl query portal.corp.example

اگر یہ 10.60.0.20 واپس دیتا ہے تو DNS معاہدہ پورا ہوا۔ اگر وقت ختم ہو جائے تو پہلے 10.90.0.1 کا راستہ، پھر فائر وال اصول، پھر سرور پر allow-query جانچیں۔ اس ترتیب میں نام حل ہونے کی ناکامیاں تقریباً ہمیشہ رسائی یا ACL ہوتی ہیں، زون فائل نہیں۔ کلائنٹ سے باہر کی طرف کام کریں، کیونکہ سرور آپ کو نہیں بتا سکتا کہ کوئی استفسار کیوں کبھی نہیں پہنچا۔

یاد رکھیں کہ ایپلیکیشن کو اب بھی اپنا راستہ اور اپنی سروس اجازت درکار ہے۔ حل شدہ نام جو ناقابل رسائی پتے کی طرف اشارہ کرتا ہے، انہی کپڑوں میں ایک اور ناکامی ہے۔

جو اب بھی خودکار نہیں

جن ایپلیکیشنز کی اپنی ریزالور منطق ہے وہ سسٹم ریزالور کو مکمل نظر انداز کرتی ہیں، اور کتنا ہی nmcli ہو، یہ نہیں بدلتا۔ DNSSEC کی تصدیق کرنے والی تنصیبات کو نجی زون کے لیے واضح ٹرسٹ اینکر ڈیزائن درکار ہے؛ جواب تصدیق بند کرنے کی عمومی ہدایت نہیں ہے۔ اسی کلائنٹ سافٹ ویئر سے جانچیں جو آپ کے صارفین چلاتے ہیں، نہ کہ ایسے اوزار سے جو اتفاقاً سسٹم ریزالور استعمال کرے۔ ان دونوں کے درمیان فرق ہی پوری بگ رپورٹ ہے۔

فلیٹ اپنے پروویژننگ نظام کے ذریعے اس کلائنٹ پالیسی کو خودکار کر سکتے ہیں، لیکن پالیسی مالک والی الگ شے رہتی ہے۔ BIND 9 حوالہ اوپر استعمال شدہ سماعت اور استفسار کے کنٹرولز کا احاطہ کرتا ہے، اور آپ کے نصب شدہ ورژن کے لیے رویے کی تصدیق کے لیے درست جگہ یہی ہے۔

اگلا قدم: زون کے سیریل اضافے اور جانچ کے احکامات اپنے تبدیلی کے طریقہ کار میں شامل کریں، تاکہ کوئی ریکارڈ ترمیم بغیر جانچے پیداوار تک نہ پہنچ سکے۔