نجی VPN نام ناکام ہو رہے ہیں؟ شبہ DNS ری بائنڈنگ تحفظ پر

دفتر کے LAN میں اندرونی نام فوراً جواب دیتا ہے۔ VPN چلنے ہی وہ کام کرنا چھوڑ دیتا ہے، ایپلیکیشن ٹائم آؤٹ بتاتی ہے، اور سرنگ خود بغیر شکایت ٹریفک گزار رہی ہے۔ جو چیز بدلی وہ ریزالور ہے، اور اُس ریزالور کی نجی پتوں کے بارے میں اپنی رائے ہے۔

ری بائنڈنگ تحفظ ایک مخصوص چال روکنے کے لیے موجود ہے۔ جان بوجھ کر شائع کیا گیا نجی نام اتنا ہی مشابہ لگتا ہے کہ دفاع متحرک ہو جائے۔

پالیسی سے پہلے جواب پڑھیں

نام اُس ریزالور سے پوچھیں جو VPN واقعی تقسیم کرتا ہے، نہ کہ اُس سے جو آپ کا لیپ ٹاپ گھر میں استعمال کرتا ہے۔ جواب کا موازنہ اُس ریکارڈ سے کریں جس کی آپ توقع رکھتے ہیں، اور لکھیں کہ جواب خالی ہے، مسترد ہوا ہے، یا اُن عوامی پتوں سے بھرا ہے جن کا کسی نے منصوبہ نہیں بنایا۔

علامات ایک دوسرے پر چڑھتی ہیں، اس لیے تشخیص جواب کی شکل طے کرتی ہے۔ NXDOMAIN گمشدہ ریکارڈ ہے، REFUSED رسائی کا قاعدہ ہے، اندرونی نام کے لیے عوامی پتہ پالیسی یا split-DNS کی غلطی ہے، اور درست نجی پتہ جسے کلائنٹ استعمال نہیں کر سکتا بالکل الگ مسئلہ ہے۔ مسترد شدہ کنکشن یا رُکا ہوا درخواست بذات خود کچھ ثابت نہیں کرتی، اسی لیے ایسے ٹکٹوں میں پہلا حکم دوبارہ چلانا نہیں بلکہ تلاش ہونا چاہیے۔ کچھ بھی بدلنے سے پہلے جواب لکھ لیں۔

دفاع واقعی کیا روکتا ہے

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

dnsmasq بالکل یہی رویہ، فی ڈومین استثناؤں کے ساتھ دستاویز کرتا ہے۔ اپنے دستورالعمل میں یہ rebind-domain-ok کو ایسے ڈومین نام دینے کا طریقہ بتاتا ہے جو قانونی طور پر ایسے پتے واپس کر سکتے ہیں۔ اِسے اِس اشارے کے طور پر پڑھیں کہ مطلوبہ درستی محدود اجازت ہے، عالمی سوئچ نہیں۔

استثنا نام کی فضا تک محدود کریں

پہلے نام کی فضا درست کریں، پھر استثنا۔ تصدیق کریں کہ ناکام نام اُس ڈومین کا ہے جسے تنظیم کنٹرول کرتی ہے اور ریکارڈ جان بوجھ کر برقرار رکھا جاتا ہے۔ مانوس LAN رینج سے صرف مشابہ غیر متوقع پتہ استثنا نہیں بلکہ شبہ کا حقدار ہے، اس لیے کوئی بھی اجازت لکھنے سے پہلے زون کے مالک کی جانچ کریں۔

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

پھر مطلوبہ ناموں کو ڈھانپنے والی سب سے تنگ اجازت شامل کریں: ایک ڈومین، یا ایک تفویض شدہ ذیلی ڈومین، اُس ریزالور کنفیگریشن میں جس سے VPN کلائنٹ پوچھتے ہیں۔ اُس ریزالور پر ہر نام کے لیے تحفظ بند کرنا اُن سبھی سے ایک ساتھ دفاع ہٹا دیتا ہے، اُن ناموں سمیت جنہیں کبھی ضرورت نہیں تھی۔

Split DNS اسی فیصلے کا حصہ ہے۔ اگر نجی نام کی فضا کا جواب صرف اندرونی ریزالور دے، تو وہیں شائع کریں اور عوامی ریزالوروں کی طرف اِس کا رساؤ روکیں، تاکہ استثنا ہر راستے کے بجائے ایک راستہ ڈھانپے۔

وسیلے اور دفاع کو دوبارہ جانچیں

دوبارہ پوچھیں، پھر سروس سے جڑیں اور دیکھیں کلائنٹ کیا دیکھتا ہے۔ چلتی سیشن کے ساتھ درست نجی جواب کا مطلب ہے استثنا لاگو ہو گیا۔ رُکی سیشن کے ساتھ درست جواب کا مطلب ہے اگلا شبہ راستہ یا سروس کی شناخت ہے۔

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

عوامی نام بھی اُسی ریزالور سے جانچیں۔ استثنا سے باہر کے ناموں کے لیے تحفظ کو اب بھی درست رویہ رکھنا چاہیے، اور اگر وہ جانچ ناکام ہو تو تبدیلی مطلوب سے زیادہ وسیع تھی۔ سرٹیفکیٹ کی توثیق کو شروع سے آخر تک نہ چھیڑیں، کیونکہ درست طور پر حل ہونے والا نام بھی اُس سرٹیفکیٹ سے میل کھانا چاہیے جو سروس پیش کرتی ہے۔

ٹکٹ میں مسترد شدہ جواب، ڈومین، ریزالور اور پالیسی کا مالک کون ہے لکھیں۔ وہی ریکارڈ پراسرار اندرونی خلل کو ایسی کنفیگریشن تبدیلی میں بدلتا ہے جس کا کوئی جائزہ لے سکے۔