OpenVPN redirect-gateway: ہر جھنڈا راستوں کے ساتھ کیا کرتا ہے

پروفائل میں redirect-gateway کے ساتھ جڑیں، اور آپ کی مشین کا طے شدہ راستہ غائب ہو سکتا ہے، دو حصوں میں بٹ سکتا ہے، یا وہیں رہ سکتا ہے جہاں تھا، یہ ان جھنڈوں پر منحصر ہے جنہیں کوئی دو بار نہیں پڑھتا۔ یہ اختیار صرف روٹنگ کی حالت بدلتا ہے اور کچھ نہیں، اس لیے اس نے کیا کیا اس کا واحد قابلِ اعتماد ثبوت وہ جدول ہے جو کلائنٹ نے بعد میں نصب کیا۔ آگے وہ جدول ہے جو جوڑنے کے بعد ہوتا ہے، وہ راستہ جو ٹنل کو خود زندہ رکھتا ہے، اور وہ IPv6 ٹریفک جسے یہ ہدایت کبھی ڈھانپنے کا دعویٰ نہیں کرتی۔ ہر قدم ایک حکم ہے جو آپ ٹنل کھلا ہونے کے دوران کلائنٹ پر چلا سکتے ہیں۔

ہر جھنڈا طے شدہ راستے کے ساتھ کیا کرتا ہے

بغیر کسی جھنڈے کے، یہ اختیار عام طے شدہ راستہ ہٹا کر اس کی جگہ ٹنل رکھ دیتا ہے، اس لیے جوڑنے کے دوران پرانا گیٹ وے جدول سے غائب ہو جاتا ہے۔ def1 شامل کریں اور وہ طے شدہ فہرست میں رہتا ہے، دو تنگ راستے کام کرتے ہیں۔ bypass-dhcp شامل کریں اور DHCP راستہ بھی بچا رہتا ہے، جو ایسے نیٹ ورک میں اہم ہے جہاں کلائنٹ کو ابھی مقامی DHCP سرور تک پہنچنا ہے۔ OpenVPN 2.6 کے دستی صفحے پر جھنڈوں کی فہرست ایک بار پڑھنے کے لیے کافی مختصر ہے، اور ہر اندراج بدلتا ہے کہ کون سے راستے جدول میں پہنچیں گے۔

دھکیلا گیا اختیار پہنچنے پر ویسا ہی برتاؤ کرتا ہے، اس لیے کلائنٹ پروفائل میں کچھ بھی نہ ہو سکتا ہے جبکہ جدول مکمل طور پر تبدیل شدہ دکھائی دے۔ یہ معمول ہے: سرور نے جھنڈے بھیجے، کلائنٹ نے انہیں لاگو کیا، اور مقامی فائل نے اس ہدایت کا کبھی ذکر نہیں کیا۔ جب دھکیل کچھ نہ کرتا دکھے، کلائنٹ کی طرف کا وہ فلٹر دیکھیں جو کھینچے گئے اختیارات قبول یا مسترد کرتا ہے، کیونکہ مسترد شدہ اختیار کسی بھی طرف کوئی خرابی پیدا نہیں کرتا۔

def1 آپ کے طے شدہ راستے کو چھوئے بغیر خصوصیت سے جیتتا ہے

دو نصف طے شدہ راستے مل کر IPv4 کی جگہ ڈھانپتے ہیں، 0.0.0.0/1 اور 128.0.0.0/1۔ ہر ایک 0.0.0.0/0 سے زیادہ مخصوص ہے، اس لیے تلاش انہیں ترجیح دیتی ہے جبکہ اصل طے شدہ راستہ جدول میں رہتا ہے ہر اس چیز کے لیے جو کم سے کم مخصوص مماثلت مانگتی ہے۔

پروفائل نہیں، جدول پڑھیں، کیونکہ آپ ان میں سے کس حالت میں ہیں یہ صرف جدول دکھاتا ہے۔ انہیں الگ کرنے کے لیے دو سطریں کافی ہیں:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

ٹنل کے آخری سرے کو قابلِ رسائی رکھیں

کلائنٹ کو ٹنل کے دور سرے تک ایسا راستہ چاہیے جو خود ٹنل سے نہ گزرے۔ OpenVPN کچھ اور بدلنے سے پہلے وہ ہوسٹ راستہ نصب کرتا ہے، اور ہاتھ سے راستہ ترمیم یا دوسرا VPN کلائنٹ اسے ہٹا سکتا ہے۔ اس کے بعد علامت ایسا جوڑ ہے جو کہتا ہے کہ جڑا ہوا ہے اور پھر کچھ نہیں گزرنے دیتا۔

ٹنل کھلا ہونے کے دوران کرنل سے پوچھیں کہ آخری سرے کے پتے کے لیے کون سا انٹرفیس استعمال کرے گا۔ جواب میں طبعی انٹرفیس اور اس کا گیٹ وے ہونا چاہیے، کبھی tun0 نہیں:

ip route get 198.51.100.20

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

IPv6 ٹریفک اپنا ہی جدول استعمال کرتا رہتا ہے

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

جوڑنے کے بعد v6 جدول دیکھیں، یہ ماننے کے بجائے کہ ٹنل نے اسے ڈھانپ لیا۔ یہ ہدایت پتہ خاندان کے جھنڈے ٹھیک اسی وجہ سے رکھتی ہے، اور انہیں چھوڑ دینے والا پروفائل پلیٹ فارم کے طے شدہ برتاؤ کو ورثے میں پاتا ہے:

ip -6 route show default
ip -6 route get 2001:db8::10

ثابت کریں کہ کوئی اطلاق کون سا انٹرفیس استعمال کرتی ہے

جڑی حالت کوئی رکاوٹ نہیں ہے، اور راستے کی تبدیلی کوئی ہنگامی سوئچ نہیں ہے۔ اگر ٹنل ناکام ہونے پر براہِ راست ٹریفک رکنا چاہیے تو وہ پالیسی فائر وال میں رہتی ہے اور اس کا اپنا امتحان درکار ہے۔

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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