OpenVPN route-nopull اصل میں سرور کو کیا بھیجنے سے روکتا ہے
route-nopull بھیجے گئے روٹس اور DHCP اختیارات کو گرا دیتا ہے، ہینڈ شیک کو نہیں۔ اس، pull-filter یا کسی کے نہ ہونے میں فیصلہ کریں، پھر روٹس خود شامل کریں۔
آپ نے کلائنٹ پروفائل میں route-nopull ڈالا تاکہ ٹنل آپ کا ڈیفالٹ روٹ نگل نہ جائے، اور اب دفتر کا سب نیٹ ناقابل رسائی ہے جبکہ کلائنٹ پھر بھی منسلک دکھاتا ہے۔ دونوں مشاہدے درست ہیں، اور کچھ بھی خراب نہیں ہوا۔ یہ پرچم کلائنٹ کو کہتا ہے کہ سرور کی بھیجی گئی روٹس اور DHCP اندراجات چھوڑ دے، جو اسے شامل کرنے والے بیشتر لوگوں کی توقع سے زیادہ محدود ہدایت ہے۔ باقی ایک چلتی ہوئی ٹنل رہ جاتی ہے جس کی کوئی رائے نہیں کہ کون سی منزلیں اسے استعمال کریں۔
یہی خلا وہ پورا فیصلہ ہے جس کے بارے میں یہ مضمون ہے۔ یا تو سرور نیٹ ورک بیان کرتا ہے یا کلائنٹ، اور یہ پرچم وہ کام کلائنٹ کے حوالے کر دیتا ہے بغیر آپ کے لیے اس کا کوئی حصہ کیے۔
پرچم کنیکٹ کے وقت کیا بند کرتا ہے
پل کرنے والا OpenVPN کلائنٹ عام طور پر تصدیق کے بعد سرور سے ایک بنڈل لیتا ہے: روٹس، ڈیفالٹ گیٹ وے کی ری ڈائریکشن، DNS سرورز اور چند ٹیوننگ ہدایات۔ route-nopull نافذ ہونے پر کلائنٹ پھر بھی سیشن قبول کرتا ہے، پھر بھی سرٹیفکیٹ کی تصدیق کرتا ہے، پھر بھی سائفرز اور keepalive پر بات کرتا ہے، اور پھر بھی انٹرفیس اٹھاتا ہے۔ جو چھوڑ دیتا ہے وہ بھیجی گئی route سطروں اور بھیجی گئی dhcp-option سطروں کا اطلاق ہے، بشمول DNS۔
الجھن ایک مردہ ایپلیکیشن کے ساتھ بیٹھی سبز نشاندہی سے آتی ہے۔ ٹنل موجود ہے؛ منزلوں سے اس ٹنل تک کا نقشہ نہیں۔ کلائنٹ کے اسٹیٹس پینل میں کوئی چیز «منسلک اور روٹ کر رہا ہے» کو «منسلک اور بے اثر» سے نہیں پہچانتی، کیونکہ ٹنل کی نظر میں دونوں ایک ہی حالت ہیں۔
چلتی ہوئی ٹنل پھر بھی کچھ کیوں روٹ نہیں کر سکتی
انٹرفیس اپنے پتے کے ساتھ ظاہر ہوتا ہے اور پوائنٹ ٹو پوائنٹ لنک پر اکثر ہم منصب تک ہوسٹ روٹ سے زیادہ مخصوص کچھ نہیں ہوتا۔ نجی سب نیٹ صرف اسی وقت قابل رسائی ہوتا ہے جب کوئی روٹ درست پری فکس کے ساتھ اس انٹرفیس کی طرف اشارہ کرے، اور پش غیر فعال ہونے پر وہ روٹ کبھی نہیں آتا۔ ڈاؤن لوڈ شدہ پروفائل بھی عام طور پر مدد نہیں کر سکتا، کیونکہ وہ اس مفروضے پر لکھا گیا تھا کہ سرور بالکل یہی معلومات فراہم کرے گا۔ اسی لیے انٹرفیس صحت مند دکھ سکتا ہے جبکہ سب نیٹ تاریک رہتا ہے۔
اس لیے پروفائل پڑھنا بہت کم ثابت کرتا ہے۔ اس کے بجائے منسلک مشین پر چلتی حالت پڑھیں:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10دوسری کمانڈ میں سب نیٹ روٹ کے بغیر پتہ اس مسئلے کی علامت ہے۔ تیسری کمانڈ وہ سوال جواب دیتی ہے جو صارفین کو واقعی اہم ہے، کیونکہ وہ اس انٹرفیس کی اطلاع دیتی ہے جو کرنل کسی مخصوص منزل کے لیے چنے گا، نہ کہ اس فہرست کی جسے آپ استعمال کرنے کی امید رکھتے تھے۔ اگر وہ آپ کے فزیکل لنک سے جواب دے، تو ٹنل راستے میں ہی نہیں ہے۔
نام کی تحلیل کسی الگ وجہ سے نہیں بلکہ متعلقہ وجہ سے ناکام ہوتی ہے۔ بھیجے گئے dhcp-option DNS اندراجات اسی پرچم سے چھوڑ دیے جاتے ہیں، لہذا داخلی ہوسٹس کے استفسارات اسی ریزالور تک جاتے ہیں جو مقامی نیٹ ورک نے فراہم کیا۔ اس ریزالور کے پاس دفتر کے لیے کوئی زون نہیں، اس لیے استفسار ناکام ہوتا ہے یا کوئی عوامی جواب واپس آتا ہے، اور ناکامی سرور کا مسئلہ لگتی ہے جبکہ وہ کلائنٹ کنفیگریشن کا مسئلہ ہے۔ نام سے پہلے پتہ جانچنا ہی دونوں کو الگ کرتا ہے۔
پرچم اور پری فکس فلٹر کے درمیان انتخاب
دونوں اختیارات ایک ہی شکایت کی مختلف شکلیں حل کرتے ہیں، اور برا انتخاب ہی «منسلک مگر بیکار» حالت پیدا کرتا ہے۔ ایک بھیجی گئی پالیسی کو مکمل طور پر بدل دیتا ہے، دوسرا اسے پری فکس کے حساب سے ترمیم کرتا ہے۔ جدول مختصر صورت دیتا ہے، اور اس کے بعد کا پیراگراف وہ حصہ بتاتا ہے جو لوگوں کو پھنسا دیتا ہے۔
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter تین فعل رکھنے والا پری فکس میچر ہے، اس لیے وہ سطروں کے ایک خاندان کو قبول کر سکتا ہے، انہیں خاموشی سے نظرانداز کر سکتا ہے، یا پری فکس آتے ہی کنکشن کو یکسر مسترد کر سکتا ہے۔ جاننے کے قابل آخری رویہ ہے: مسترد کرنے کا قاعدہ پالیسی کے اختلاف کو خاموش گریز کے بجائے ناکام ہینڈ شیک بنا دیتا ہے۔ OpenVPN 2.6 دستورالعمل قبول شدہ پری فکسز اور ہر فعل کے قطعی معنی کی فہرست دیتا ہے۔
ایک عام درمیانی راستہ یہ ہے کہ صرف redirect-gateway مسترد کریں اور دفتر کے روٹس اور DNS کو حسب منشا آنے دیں۔ یہ پش کو ان حصوں کے لیے چلتا رکھتا ہے جنہیں سرور آپ سے بہتر سمجھتا ہے، اور ساتھ ہی اس واحد سطر کو روکتا ہے جو آپ کا ڈیفالٹ روٹ لے لیتی۔
روٹس اور ریزالور خود شامل کرنا
اگر آپ پرچم رکھتے ہیں، تو پروفائل کو وہی کہنا ہوگا جو سرور کہتا۔ کلائنٹ کی طرف کے route ہدایات کنکشن قائم ہونے کے بعد لاگو ہوتی ہیں، اس لیے وہ پرچم کے ساتھ مل کر کام کرتی ہیں نہ کہ اس سے رکی جاتی ہیں۔ انہیں پروفائل میں رکھیں، کسی انٹرایکٹو کمانڈ لائن میں نہیں، ورنہ اگلا دوبارہ کنیکٹ چلتی حالت دوبارہ پیدا نہیں کرے گا۔
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS کی سطر عجیب مقام پر ہے: یہ کلائنٹ کی طرف کی ہدایت ہے، لیکن کچھ کلائنٹس اسے صرف پلیٹ فارم کے DNS انٹیگریشن کے ذریعے لاگو کرتے ہیں، جو لنک بدلنے پر اسے اوور رائٹ کر سکتا ہے۔ systemd والے ہوسٹ پر ریزالور کو براہ راست ٹنل انٹرفیس پر مقرر کرنا اس امید سے زیادہ قابل پیش گوئی ہے کہ کلائنٹ ترجیح کی دوڑ جیت جائے گا:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comروٹنگ ڈومین پتے جتنا ہی اہم ہے۔ اس کے بغیر، عوامی ناموں کے استفسارات بھی داخلی ریزالور کو بھیجے جا سکتے ہیں، اور کوئی بھی داخلی ریزالور جو ریکرشن سے انکار کرے براؤزنگ توڑ دے گا جبکہ نجی زون چلتا رہے گا۔ اس کے ساتھ، صرف اسی لاحقے کے نام ٹنل ریزالور کو بھیجے جاتے ہیں اور باقی سب فزیکل لنک کی پیروی کرتا ہے۔
نتیجہ جانچنا: پتہ، نام اور بیرونی راستہ
تین ٹیسٹ ممکنہ ناکامیوں کو الگ کرتے ہیں۔ نجی پتہ IP سے حاصل کریں، پھر وہی ہوسٹ نام سے، پھر کوئی عام عوامی سائٹ۔ چلنے والا IP اور ناکام نام ریزالور کی طرف اشارہ کرتا ہے؛ ناکام IP اور چلنے والا نام روٹنگ کی طرف اشارہ کرتا ہے؛ دونوں ناکام ہوں تو عام طور پر مطلب یہ ہے کہ ٹنل راستے میں نہیں۔
پھر اندر کی طرف نہیں بلکہ باہر کی طرف دیکھیں۔ ٹنل اینڈ پوائنٹ کا اپنا روٹ تبدیلی سے بچنا چاہیے، اور ناکامی کو روکنے کو ٹنل تک محدود رکھنا چاہیے بغیر اینڈ پوائنٹ کو پکڑے۔ ٹنل گرنے کے بعد بھی براؤز کرنے والا کلائنٹ پالیسی کا مسئلہ ہے، روٹنگ کا نہیں، اور وہ اوپر کے تینوں ٹیسٹوں میں ظاہر نہیں ہوگا۔
حتمی فہرست پروفائل کی دستاویز میں لکھیں: روٹس، ریزالور، ڈومینز، اور ہر ایک کے موجود ہونے کی وجہ۔ وہی جدول دوبارہ پیدا کرنے والا دوبارہ کنیکٹ ہی اس بات کا واحد ثبوت ہے کہ مقامی پالیسی مکمل ہے۔ اگر ٹنل اٹھا ہوا ہو اور تینوں ٹیسٹ گزر رہے ہوں اور ایپلیکیشنز پھر بھی ناکام ہوں، تو اگلی جگہ سرٹیفکیٹس نہیں جن کی تصدیق ہو چکی، بلکہ «منسلک مگر آف لائن» قسم کے مسائل ہیں۔