اسپلٹ ٹنل دستاویزات کو ہر راستے کے ساتھ DNS قاعدہ درکار ہے
راستہ پتے سے فیصلہ کرتا ہے، ریزولور نام سے فیصلہ کرتا ہے۔ ہر بہاؤ کے لیے دونوں منتخب کنندگان لکھیں، ہر ایک کے ساتھ ایک جانچ، ورنہ DNS بدلنے پر نوٹ ناکام ہو جائے گا۔
"دفتری ٹریفک VPN سے گزرتی ہے" کہنے والا اسپلٹ ٹنل نوٹ ایک فیصلہ درج کر چکا ہے اور مزید تین کی طرف اشارہ کرتا ہے۔ پیکٹ کی پرت پر ایک روٹنگ جدول منزل کے پتے سے انٹرفیس چنتا ہے؛ نام کی پرت پر ریزولور استفسار سے سرور چنتا ہے، اور یہ دونوں انتخاب الگ الگ کیے جاتے ہیں۔ اسی لیے درست طور پر درج کردہ سابقہ بھی ایسی مشین بنا سکتا ہے جو اندرونی نام کو عوامی پتے میں حل کرے، یا راستہ کامل دکھنے کے باوجود کچھ بھی حل نہ کرے۔
دو منتخب کنندگان، ایک کنکشن کی کوشش
جب کوئی اطلاقیہ files.corp.example سے جڑتا ہے تو پیکٹ وجود میں آنے سے پہلے دو تلاشیں ہوتی ہیں۔ ریزولور فیصلہ کرتا ہے کہ کون سا سرور استفسار وصول کرے گا، تلاش کے ڈومین، فی لنک روٹنگ ڈومین یا واضح پروفائل قاعدہ استعمال کرتے ہوئے۔ پھر روٹنگ جدول فیصلہ کرتا ہے کہ نتیجے میں آنے والا پتہ کہاں جائے گا، منزل کے ساتھ طویل ترین سابقہ مماثلت استعمال کرتے ہوئے۔
کوئی چیز ان دو فیصلوں کو نہیں جوڑتی۔ ایک نجی زون 10.20.4.11 سے جواب دے سکتا ہے، جبکہ روٹنگ جدول 10.20.0.0/16 سرنگ میں بھیجتا ہے، اور کنکشن کام کرتا ہے۔ دونوں میں سے کوئی بھی الٹ دیں اور یہ دوسرے جیسا دکھنے والے انداز میں ناکام ہوتا ہے: درست DNS پالیسی اور غائب راستہ حل شدہ نام اور وقت کی حد دیتے ہیں، جبکہ درست راستہ اور عوامی ریزولور ایسا پتہ دیتے ہیں جو صاف طور پر غلط جگہ کی طرف روٹ ہوتا ہے۔
منقسم افق DNS اسے مزید تیز کرتا ہے۔ ایک ہی نام اندرونی ریزولور سے نجی پتہ اور انٹرنیٹ کی طرف دیکھنے والے ریزولور سے عوامی پتہ واپس کر سکتا ہے، اس لیے صرف سابقہ درج کرنے والا نوٹ یہ اندازہ نہیں لگا سکتا کہ کلائنٹ اصل میں کون سا پتہ استعمال کرے گا۔ ریزولور کا راستہ لکھیں ورنہ پتہ ایک اندازہ ہے۔
صرف راستے والا نوٹ کیا چھوڑ دیتا ہے
صرف راستے کا ریکارڈ اسپلٹ ٹنل کی سب سے عام ناکامی کے لیے بیکار ہے: نام۔ صارف بتاتا ہے کہ اندرونی نیٹ ورک لوڈ نہیں ہوتا، سرنگ فعال ہے اور سابقہ موجود ہے۔ جو ٹکٹ لیتا ہے اس کے پاس اس کا ریکارڈ نہیں کہ کس ریزولور کو جواب دینا چاہیے تھا، غلط تلاش لاحقہ کو مسدود سرور سے الگ پہچاننے کا طریقہ نہیں، اور موازنے کے لیے بنیادی لکیر نہیں۔
دوسری کمی استثناؤں کی فہرست ہے۔ اسپلٹ ٹنل کا ڈیزائن اتنا ہی اس بات سے متعین ہوتا ہے کہ سرنگ سے باہر کیا رہتا ہے جتنا اس سے کہ اندر کیا آتا ہے، اور خارج شدہ حدود ہی عموماً پہلے ٹوٹتی ہیں، کیونکہ زیادہ مخصوص مقامی راستہ یا کلائنٹ کی طرف کا فلٹر پروفائل کو چھوئے بغیر نیت کو پلٹ سکتا ہے۔
تیسری سرنگ کا دور والا سرا ہے۔ کلائنٹ کا راستہ پیکٹ کو صرف تار پر رکھتا ہے؛ گیٹ وے کو اب بھی اسے آگے بھیجنا اور واپسی کا راستہ رکھنا ہے۔ strongSwan کی آگے بھیجنے کی رہنما یاد دلاتی ہے کہ گیٹ وے پر آگے بھیجنے اور فائر وال کے قواعد خصوصیت کا حصہ ہیں، نہ کہ اس پلمبنگ کا حصہ جسے آپ فرض کر سکتے ہیں۔
وہ خانے جو نوٹ کو قابل عمل بناتے ہیں
ہر بہاؤ کے لیے ایک سطر، اور بہاؤ یعنی منزل جمع نام جمع مالک۔ یہ وہ خانے ہیں جو کسی حقیقی واقعے سے رابطے میں قائم رہتے ہیں:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"یہ کہاں رہتا ہے" والی سطر وہی ہے جسے لوگ چھوڑ دیتے ہیں۔ سرور کی دھکیلی ہوئی سابقہ، کلائنٹ پروفائل کی شامل کردہ راستہ اور شیل میں ٹائپ کردہ راستہ اس بات میں مختلف ہیں کہ کون انہیں بدل سکتا ہے اور کیا وہ دوبارہ جڑنے پر قائم رہتے ہیں۔ اس خانے کے بغیر اگلا انجینئر نہیں بتا سکتا کہ تینوں میں سے کون سا دیکھ رہا ہے۔
ہر قاعدے کے لیے ایک جانچ، ہر سرنگ کے لیے نہیں
ہر سطر کو دو بے ضرر جانچیں درکار ہیں: ایک راستے کی، ایک نام کی۔ راستے کے لیے، ایسی چیز طلب کریں جسے سرنگ پار کرنی ہی لازم ہو اور رسائی کے بجائے راستے کی تصدیق کریں، مثلاً tracert -d 10.20.4.11 Windows پر یا ip route get 10.20.4.11 Linux پر۔ نام کے لیے، نجی نام کا استفسار کریں اور درج کریں کہ کس سرور نے جواب دیا، نوٹ کے بتائے ہوئے ریزولور کے خلاف resolvectl query files.corp.example یا dig files.corp.example استعمال کرتے ہوئے۔
منفی توقع بھی شامل کریں: سرنگ بند ہونے پر کیا ہونا چاہیے۔ VPN کے بغیر بلاک فعال والے Android یا iOS آلے پر خارج شدہ اطلاقیے کے پاس شاید کوئی کنیکٹیویٹی ہی نہ ہو، اور ڈیسک ٹاپ کلائنٹ سرنگ کے دوبارہ جڑنے کے دوران اسی اطلاقیے کو چلتا رہنے دے سکتا ہے۔ مطلوبہ جواب درج کرنا "VPN نے میری ایپ توڑ دی" کو قابل جانچ بیان بنا دیتا ہے۔
ریکارڈ کو ترتیب کے ساتھ رکھیں
نوٹ کو اس پروفائل کے ساتھ محفوظ کریں جس کی یہ وضاحت کرتا ہے اور اسی پروفائل کے ساتھ نسخہ دیں۔ ویکی میں وہ دستاویز جسے کوئی اپ ڈیٹ نہیں کرتا افواہ ہے؛ دھکیلے گئے راستوں اور ریزولور پالیسی والے اسی ذخیرے میں جدول اسی تبدیلی میں جائزہ لیا جا سکتا ہے۔
جب کچھ ٹوٹے، تو دوسری استثنا شامل کرنے سے پہلے لاگو راستے اور مؤثر ریزولور کا ریکارڈ سے موازنہ کریں۔ تین عام وجوہات میں سے دو — پرانا نام کی جگہ کا قاعدہ اور اطلاقیے کی پالیسی سے باہر مددگار عمل — بالکل VPN کی خرابی جیسے دکھتے ہیں اور اگر نوٹ صرف سابقے گنواتا ہے تو نظر نہیں آتے۔
نوٹ کو مکمل کہنے سے پہلے تصدیق کریں کہ یہ ان کا تحریری جواب دیتا ہے: کون سا سابقہ، کس پتہ خاندان کے لیے؛ کون سی نجی نام کی جگہ، کس ریزولور نے جواب دیا؛ کون سے نام جان بوجھ کر عوامی رہتے ہیں؛ ہر قاعدہ کہاں ترتیب دیا گیا ہے اور اس کا مالک کون ہے؛ اور راستہ ثابت کرنے والا ایک حکم اور نام ثابت کرنے والا ایک حکم۔ اگر ان میں سے کچھ غائب ہو تو اگلے واقعے کی تشخیص صفر سے ہوگی۔