bypass-dhcp دراصل OpenVPN کے راستے کے منصوبے میں کیا شامل کرتا ہے

redirect-gateway def1 bypass-dhcp رکھنے والا پروفائل IPv4 کے طے شدہ راستے کی جگہ لینے کو ایک تنگ استثنا کے ساتھ جوڑتا ہے۔ لوگ آخری لفظ پڑھ کر موبائل کنکشن کے لیے عام حل کی توقع کرتے ہیں، پھر ایسی DHCP تھیوری پر دوپہر گزار دیتے ہیں جس کی اس فلیگ نے کبھی حمایت نہیں کی۔ ہر حصہ ایک کام کرتا ہے، اور استثنا اپنی شہرت سے بہت چھوٹا ہے۔

صرف موبائل نیٹ ورک کی ناکامی کو پتہ مختص کرنے پر ڈالنے سے پہلے فلیگ الگ الگ دیکھیں۔ اس سٹرنگ کے دونوں حصوں کا ایک دوسرے سے کوئی تعلق نہیں۔

دو فلیگ، دو غیر متعلق کام

def1 کے ساتھ، کلائنٹ پہلے سے موجود طے شدہ راستہ بدلنے کے بجائے دو IPv4 آدھے طے شدہ راستے شامل کرتا ہے۔ 0.0.0.0/1 پتوں کی جگہ کا نچلا آدھا حصہ ڈھکتا ہے اور 128.0.0.0/1 اوپر کا آدھا، اس لیے مل کر وہ ہر منزل تک پہنچتے ہیں جبکہ ہر ایک 0.0.0.0/0 سے زیادہ مخصوص رہتا ہے۔ اس لیے اصل طے شدہ راستہ ان تلاشوں کو جیتے بغیر جدول میں رہتا ہے، جو پرانے گیٹ وے کو ہر اس چیز کے لیے قابل رسائی رکھتا ہے جسے کلائنٹ واضح طور پر روٹ کرتا ہے۔ یہ جدول میں دو ایک دوسرے پر چڑھنے والے طے شدہ راستے بھی چھوڑتا ہے، اسی لیے روٹ ڈمپ پروفائل کے اشارے سے زیادہ عجیب لگ سکتا ہے۔

bypass-dhcp الگ ہے، اور طے شدہ راستے کو بالکل نہیں چھوتا۔ OpenVPN 2.6 کی دستی اسے مقامی سب نیٹ پر نہ ہونے والے DHCP سرور تک براہ راست راستہ شامل کرنا بتاتی ہے، تاکہ لیز ٹریفک سرنگ سے باہر جائے، اور نوٹ کرتی ہے کہ یہ رویہ Windows کلائنٹس پر نافذ ہے اور کہیں اور دستیاب نہ ہو سکے۔

اس کے وجود کی وجہ میکانیکی ہے۔ ایک بار آدھے طے شدہ راستے باہر جانے والا ٹریفک پکڑ لیں، تو جسمانی نیٹ ورک کے سرور کی طرف بھیجی گئی DHCP تجدید سرنگ میں روٹ ہو جائے گی جب تک کوئی اس پتے کو حقیقی انٹرفیس سے نہ باندھے۔ فلیگ اسے باندھتی ہے۔

استثنا دراصل کس حد تک ہے

کامیاب کنکشن کے بعد ایک مثالی جدول شکل دکھاتا ہے: سرنگ کے ذریعے دو آدھے طے شدہ راستے، اور جسمانی گیٹ وے کے ذریعے DHCP سرور کے لیے ایک ہوسٹ راستہ۔ اسے شکل کے طور پر پڑھیں، اپنے پتوں کے طور پر نہیں۔

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

دیکھیں کہ کلائنٹ نے واقعی کیا نصب کیا

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

VPN کے آخری نقطے تک راستے کو بھی اسی وقت قابل استعمال رکھیں۔ یہ آخری نقطے کا استثنا DHCP استثنا سے مختلف تقاضا ہے، اور اس کے بغیر سرنگ خود کو قائم رکھنے والی ترسیل کو پکڑ سکتی ہے۔

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

باقی راستہ اس فلیگ میں نہیں ہے

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

ناموں کا حل اور IPv6 دونوں کو اپنی پالیسی چاہیے۔ IPv4 کی جگہ لینا نہ ریزیولور کو سرنگ کی طرف کے سرور کی جانب موڑتا ہے اور نہ IPv6 کوریج قائم کرتا ہے، اور صرف v4 کو ری ڈائریکٹ کرنے والا کلائنٹ v6 راستہ اچھوتا چھوڑ دیتا ہے۔

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