روٹر پر VPN قواعد: ماخذ اور منزل کو ملائیں

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

خصوصیت کا نام دو سرے چھپاتا ہے

وہ میڈیا پلیئر جو ٹنل استعمال کرے وہ ماخذ-مطابقت ہے۔ وہ نجی دفتر کا سابقہ جو ٹنل کے ذریعے قابلِ رسائی ہو وہ منزل-مطابقت ہے۔ وہ ورک سٹیشن جو ٹنل صرف ایک سروس کے لیے استعمال کرے وہ دونوں ہے، اور وہی تقاطع وہ صورت جسے زیادہ تر صارفی فرم ویئر بری طرح سنبھالتا ہے ہے۔

مصنوعات کا موازنہ کرنے سے پہلے ضرورت کو جوڑی کے طور پر لکھیں۔ وہی جوڑی آپ بعد میں جانچیں گے۔

جو مصنوعہ آلات کی فہرست یا عالمی منزلوں کی فہرست دیتا ہے وہ شاید «صرف یہ آلہ، صرف یہ منزلیں» بیان نہ کر سکے۔ یہ فرق ظاہری نہیں: عالمی منزل کا قاعدہ ہر آلے کی ٹریفک اس سائٹ کی طرف ٹنل سے بھیجتا ہے، اور آلے کا قاعدہ اس آلے کی ساری ٹریفک بھیجتا ہے۔ کوئی بھی ضرورت نہیں۔ اسکرین پر بھروسا کرنے سے پہلے وہ صورت دو آلات سے جانچیں۔

قاعدے کو تقاطع کے طور پر بنائیں

جدول ڈیزائن کو دیانت دار رکھتا ہے۔ منظر نامہ بائیں رکھیں، پھر بھیجنے والے کی مطابقت اور ہدف کی مطابقت الگ الگ نام دیں:

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

ماخذ کی شناخت مستحکم رکھیں۔ DHCP ریزرویشن، مخصوص حصہ یا آلے کی شناخت کا طریقہ کار سب کام کرتے ہیں، لیکن لیز ختم ہونے کے بعد بدلنے والا پتہ کام نہیں کرتا۔ IPv6 شامل کریں، کیونکہ ایک IPv4 پتہ آلے کی ساری ٹریفک کی شناخت نہیں کرتا۔

اوورلیپ کا فیصلہ ترجیح کرتی ہے

قواعد کا اوورلیپ عام ہے۔ وسیع آلہ قاعدہ اور تنگ منزل قاعدہ دونوں ایک ہی بہاؤ بیان کر سکتے ہیں، اور دستاویزی ترجیحی ترتیب فیصلہ کرتی ہے کہ کون جیتتا ہے۔ دلکش سیٹنگز اسکرین آپ کو وہ ترتیب نہیں بتاتی۔

ترتیب اور عدمِ مطابقت والی صورت کے لیے دستی کتابچہ پڑھیں، پھر دونوں کو اس ٹریفک سے جانچیں جو آپ دیکھ سکیں:

ip rule show
ip route get 203.0.113.10

اگر دستاویزات ترتیب نہ بتائیں تو فرض کریں کہ تنگ قاعدہ شاید نہ جیتے اور اسی حساب سے ڈیزائن کریں۔ دو ایسے قواعد جن کا آپس میں ٹکراؤ نہ ہو سکے، ان کی حمایت ایک ہوشیار قاعدے سے آسان ہے جس کی ترجیح غیر دستاویزی ہو۔

ناموں کو تازگی کی پالیسی چاہیے

ڈومین کے طور پر لکھی گئی منزل دیکھ بھال کا مسئلہ بڑھاتی ہے۔ روٹر کو اسے حل کرنا ہوگا، نقشہ تازہ کرنا ہوگا، متعدد پتے اور ذیلی ڈومین سنبھالنے ہوں گے، اور ایپلیکیشن DNS کا سامنا کرنا ہوگا جو متوقع حل کنندہ کو نظرانداز کرتا ہے۔

ایک تلاش کے نتیجے کو IP قاعدے میں نقل کرنا ایک سنیپ شاٹ ہے، ڈومین پالیسی نہیں۔

فیصلہ کریں کہ قاعدہ غلط ہونے سے پہلے جواب کتنا پرانا ہو سکتا ہے، اور حل ناکام ہونے پر روٹر کیا کرتا ہے۔ آخری معلوم پتہ رکھنے والا قاعدہ خدمت کی منتقلی سے گزر سکتا ہے؛ اندراج پھینکنے والا قاعدہ ٹنلنگ خاموشی سے روک سکتا ہے۔ دونوں رویے قابلِ قبول ہیں اگر وہ قاعدے کے ساتھ لکھے ہوں۔

عدم دستیابی کی حالت متعین کریں

راستے کی ترجیح صرف-VPN ٹریفک لازم نہیں کرتی۔ جب ٹنل بند ہو تو روٹر بہاؤ روک سکتا ہے، سیدھا بھیج سکتا ہے یا دوسری ٹنل استعمال کر سکتا ہے، اور ہر انتخاب کی ناکامی کی علامت مختلف ہے۔

فیصلہ کریں کہ ضرورت کو کون سا چاہیے، پھر ٹنل بند کر کے اور بہاؤ دیکھ کر اس کی تصدیق کریں:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

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