آپ کا اسپلٹ ٹنل ایپ تک پہنچتا ہے مگر اس کے DNS سرور تک نہیں
اسپلٹ ٹنل ایپ کے سب نیٹ کو روٹ کر سکتا ہے اور پھر بھی اس کے پاس بیٹھا حل کنندہ چھوڑ سکتا ہے۔ ہوسٹ روٹ شامل کریں، پھر دیکھیں کہ Windows دراصل کون سا سرور منتخب کرتا ہے۔
ایپ کے سب نیٹ کو روٹ کرنا اسپلٹ ٹنل کا واضح حصہ ہے اور یہ پورا کام نہیں۔ حل کنندہ اکثر اس ایپ سے مختلف پتے پر بیٹھتا ہے جس کی وہ خدمت کرتا ہے، اس لیے کام کرتا ٹنل بھی تلاش کو اس سے باہر چھوڑ سکتا ہے۔ جو پروفائل صرف 10.80.0.0/16 لے کر چلتا ہے اور کچھ نہیں، وہ 10.90.0.53 کے لیے استفسار مقامی انٹرفیس سے بھیجتا ہے، جہاں کوئی نجی زون نہیں۔ حل کنندہ کا راستہ شامل کریں، پھر مسئلے کا دوسرا نصف دیکھیں: کلائنٹ دراصل کون سا سرور منتخب کرتا ہے۔
افسانہ: ایک راستہ پوری خدمت کو ڈھانپ لیتا ہے
اسپلٹ ٹنل ان منزلوں کی فہرست ہے جو کنکشن سے گزرتے ہیں، کسی خدمت کی تفصیل نہیں۔ ایپ کا سب نیٹ اور حل کنندہ کا پتہ دو منزلیں ہیں، اور پروفائل ایک کو دوسرے کے بغیر لے جا سکتا ہے۔ جب ایسا ہوتا ہے، ایپ پتے سے قابل رسائی ہوتی ہے مگر اس کا نام ناکام ہوتا ہے، جو روٹنگ کی خلا کی بجائے DNS خرابی جیسا لگتا ہے۔
حل کنندہ کے ارد گرد کا سب نیٹ بھی خودبخود ڈھکا نہیں جاتا۔ ایک پتے کے لیے ہوسٹ روٹ اس حل کنندہ کے لیے کافی ہے اور اس کے پڑوسیوں کو نہیں کھولتا۔ ہوسٹ روٹ کا مطلب یہی ہے: بناوٹ میں تنگ، اور اگلی خدمت اسی سب نیٹ میں آنے پر بھولنا آسان۔
تلاش کے کام کرنے کے لیے تین باتیں درست ہونی چاہئیں: کلائنٹ حل کنندہ کا پتہ ٹنل سے روٹ کرے، گیٹ وے وہ درخواست قبول کرے اور آگے بھیجے، اور حل کنندہ جو ماخذ ملتا ہے اسے قبول کرے۔ جواب بھی طے شدہ راستے سے واپس آنا چاہیے۔ ان میں سے کوئی ایک بھی نہ ہو تو علامت وہی رہتی ہے، اس لیے ترتیب کو چھونے سے پہلے پتوں کی جدول لکھ لینا بہتر ہے۔
طے کریں کہ پروفائل کو کون سے پتے لے جانے ہیں
منزلیں ترتیب سے لکھیں: ایپ کا نیٹ ورک، حل کنندہ کا پتہ اور وہ عوامی اختتامی نقطہ جو خود ٹنل کو ختم کرتا ہے۔ تیسرے کو کبھی ٹنل کے اندر روٹ نہیں کرنا چاہیے، کیونکہ بیرونی کنکشن کو ایسا راستہ چاہیے جو ٹنل سے پہلے موجود ہو۔
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS کے لیے UDP اور TCP دونوں شامل کریں، کیونکہ عمل درآمد سے UDP کے ساتھ TCP کی حمایت متوقع ہے، اور بند شدہ TCP راستہ صاف ناکامیوں کی بجائے سست، جزوی ناکامیاں پیدا کرتا ہے۔ اگر نجی زون IPv6 کے ذریعے بھی خدمت کیا جاتا ہے، تو مساوی ہوسٹ استثنا IPv6 پتہ اور سابقہ استعمال کرتا ہے اور یہ الگ اندراج ہے۔
کچھ شامل کرنے سے پہلے لکھیں کہ پروفائل پہلے سے کیا ڈھانپتا ہے۔ دوہرا راستہ بے ضرر ہے، مگر غیر متوقع موجودہ راستہ آپ کو بتاتا ہے کہ پروفائل آپ کو ملنے والے پتہ منصوبے سے مختلف منصوبے کے لیے بنایا گیا تھا۔
کنکشن کے مالک کے ذریعے ہوسٹ روٹ شامل کریں
مقامی طور پر منظم اصل Windows پروفائل کے لیے، راستہ مشین کی عالمی روٹنگ جدول کی بجائے کنکشن کا ہے۔ پہلے اضافے کا پیش منظر دیکھیں، پھر اسے اسی دائرے کے ساتھ لاگو کریں جو پروفائل استعمال کرتا ہے۔
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
پہلا حکم کچھ نصب کیے بغیر تبدیلی کا پیش منظر دکھاتا ہے، اور دوسرا ان راستوں کی فہرست دیتا ہے جو پروفائل اس وقت لے جا رہا ہے۔ Microsoft کا Add-VpnConnectionRoute حوالہ ہر صارف اور تمام صارفین کے دائروں کی دستاویز کرتا ہے؛ تمام صارفین کے پروفائل کو اپنا دائرہ پیرامیٹر درکار ہے، اور تمام صارفین کے پروفائل کے خلاف ہر صارف کا حکم ناکام ہوتا ہے یا غلط جگہ پہنچتا ہے۔
جب پروفائل منظم ہو یا فروشندہ کے کلائنٹ سے آئے، تو تبدیلی اسی مالک کی ہوتی ہے۔ کنکشن پالیسی پر مستقل نظام راستہ چڑھانا تب تک کام کرتا ہے جب تک پالیسی دوبارہ لاگو نہ ہو اور راستہ غائب نہ ہو جائے، جو عام طور پر مدد کی کال کے دوران ہوتا ہے نہ کہ جانچ کے دوران۔ وہ ناکامی خاموش ہے: راستہ غائب ہوتا ہے، نام حل ہونا بند ہو جاتا ہے، اور کوئی دو واقعات کو نہیں جوڑتا۔ تبدیلی کو مالک کے اپنے ریکارڈ میں رکھیں تاکہ اگلا دوبارہ اطلاق اسے مٹانے کی بجائے لے کر چلے۔
لاگو کرنے کے بعد راستہ نافذ ہو گیا مان لینے کی بجائے پروفائل دوبارہ جوڑیں۔ زندہ کنکشن پر راستے کی تبدیلیاں ہمیشہ نہیں اٹھائی جاتیں، اور دوبارہ جوڑنا وہ کیفیت بھی دوبارہ پیدا کرتا ہے جو آپ کے صارفین کو دراصل ہوگی۔
دیکھیں کہ کلائنٹ نے دراصل کون سا حل کنندہ استعمال کیا
راستہ حل کنندہ کو مخاطب کردہ پیکٹوں کو کنٹرول کرتا ہے۔ یہ طے نہیں کرتا کہ کون سے نام وہاں بھیجے جائیں، اور وہ انتخاب الگ طریقہ کار ہے۔ Windows میں موثر نام کی جگہ کے قواعد ہر ڈومین کے لیے حل کنندہ منتخب کر سکتے ہیں، جبکہ پروفائل کی DNS ترتیبات ڈیفالٹ دیتی ہیں۔ یہ دو پرتیں کوئی خرابی پیدا کیے بغیر مختلف ہو سکتی ہیں، اس لیے براہ راست استفسار آدھا ثبوت ہے۔
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
پہلا حکم نافذ نام کی جگہ کی پالیسی چھاپتا ہے، اور دوسرا نجی حل کنندہ سے براہ راست ایپ کا نام پوچھتا ہے۔ براہ راست جواب ثابت کرتا ہے کہ راستہ اور حل کنندہ کام کرتے ہیں؛ یہ ثابت نہیں کرتا کہ ایپ کی اپنی تلاش نے وہی سرور منتخب کیا۔ اس کا موازنہ اسی نام کی عام تلاش اور ایپ کو ملنے والے جواب سے کریں۔
کیشے اور براؤزر کی سطح کے محفوظ DNS کو مدنظر رکھیں، جو صارف کے لکھے ناموں کے لیے نظام کے حل کنندہ کو مکمل طور پر نظرانداز کر سکتا ہے۔ تلاش کا لاحقہ ایک اور گمراہ کن سراغ ہے: یہ مختصر نام کو مکمل طور پر اہل نام میں پھیلاتا ہے اور اس سے کوئی تعلق نہیں کہ کون سا سرور جواب دیتا ہے۔
آخر میں دوبارہ جڑیں اور عام تلاش دہرائیں، پھر تصدیق کریں کہ عام براؤزنگ اب بھی اپنی منظور شدہ پالیسی کی پیروی کرتی ہے۔ غیر متعلق نام کے حل ہونے کے لیے نجی حل کنندہ کو عوامی سے بدلنا اصلاح نہیں، اور یہ نجی استفسارات کو خاموشی سے وہاں لے جاتا ہے جہاں انہیں کبھی نہیں جانا چاہیے تھا۔