الگ اخراج: usb0 پر VPN پول، eth0 پر گیٹ وے کا ٹریفک

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

یقینی بنائیں کہ ماخذ پتہ روٹنگ کے فیصلے تک باقی رہتا ہے

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

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

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

ایک مکمل منتخب جدول بنائیں

جدول کسی دوست کے ساتھ طے شدہ راستہ نہیں ہے۔ اسے کافی راستے چاہیے تاکہ ہر تلاش اسی کے اندر حل ہو، بشمول WAN ذیلی نیٹ کا جڑا ہوا راستہ تاکہ اگلا ہاپ قابل رسائی ہو۔ tun1 پر 10.77.0.0/24 پول، اگلے ہاپ 203.0.113.1 کے ساتھ WAN پتہ 203.0.113.20/24، اور جدول 600 کے لیے:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

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

پھر سوچیں کہ جدول میں کیا نہیں ہے۔ جس منزل کا راستہ صرف مرکزی میں ہے، مثلاً eth0 سے قابل رسائی انتظامی ذیلی نیٹ، وہ جدول 600 میں نہیں ملے گا اور وہاں طے شدہ ہونے پر مرکزی میں واپس نہیں جائے گا۔ اگر وہ راستے اہم ہیں تو انہیں واضح طور پر منتخب جدول میں شامل کریں، جو VPN کے اخراج کے جدول کے لیے عام طور پر درست جواب ہے۔

سننے والے کی اپنی ٹریفک کو پالیسی سے باہر رکھیں

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

واپسی راستے کی چھانٹی بھی اسی سبب سے دیکھنے کے لائق ہے۔ جب کلائنٹس کو جوابات usb0 سے جاتے ہیں جبکہ درخواست کسی اور لنک سے آئی تھی، تو سخت rp_filter ترتیب ایسے پیکٹ گرا سکتی ہے جنہیں روٹنگ پالیسی درست سمجھتی ہے۔ یہ نتیجہ اخذ کرنے سے پہلے کہ قاعدہ ناکام ہوا، دونوں انٹرفیسوں پر مؤثر sysctl اقدار جانچیں۔

مشین کی ہر دوسری چیز کے مقابلے ترتیب بھی اہم ہے۔ Docker پل، دوسرا VPN اور فراہم کنندہ کی امیج سے پہلے سے موجود کوئی بھی قاعدہ سب ترجیحات شامل کرتے ہیں، اس لیے ترجیح 100 کو تنہا ماننے کے بجائے پوری قواعد کی فہرست پڑھیں۔

فارورڈنگ اور ترجمے کو راستے سے ہم آہنگ کریں

روٹنگ اوپری لنک منتخب کرتی ہے؛ یہ فارورڈ کرنے کی اجازت نہیں دیتی۔ کرنل میں IPv4 فارورڈنگ فعال ہونی چاہیے، اور فائر وال کو کلائنٹ سے WAN کی سمت اور واپسی ٹریفک قبول کرنی چاہیے۔ بہاؤ گرا دینے والی FORWARD زنجیر کے ساتھ درست جدول وہی علامت دیتا ہے جو غائب راستہ دیتا ہے، اس لیے دونوں ایک ہی مرحلے میں جانچے جاتے ہیں۔

اگر دوسرا WAN نجی پول کو آپ کی طرف واپس روٹ نہ کرے تو اس اخراج پر ماخذ کا ترجمہ کریں۔ متحرک پتے والے انٹرفیس کے لیے پول اور انٹرفیس تک محدود تنگ masquerade قاعدہ معمول کا انتخاب ہے:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

راستے مختلف ہوں تو ٹنل کا اضافی بوجھ بھی توجہ مانگتا ہے۔ اگر کلائنٹ بڑا TCP MSS طے کریں اور متبادل WAN کا MTU کم ہو یا اس کے اندر ٹنل ہو، تو بڑے قطعے رک جاتے ہیں جبکہ چھوٹے چلتے ہیں۔ فارورڈنگ راستے پر MSS کو محدود کرنا اسے وقفے وقفے سے رکنے کے بجائے قابل اندازہ رویہ بنا دیتا ہے۔

فیصلہ کریں کہ usb0 غائب ہونے پر کیا ہوگا

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

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

استحکام آخری شے ہے۔ دونوں لنکس کا مالک جو بھی ہو، چاہے نیٹ ورک مینیجر ہو، بھیجنے والی اسکرپٹ ہو یا کنکشن کی زندگی کا چکر، اسے ہر دوبارہ جڑنے پر نقل شامل کیے بغیر راستے اور قاعدہ دوبارہ بنانا ہوں گے۔ کسی حقیقی کلائنٹ کی درخواست اور گیٹ وے سے الگ درخواست کے ساتھ تصدیق کریں، دونوں میں مشاہدہ شدہ اخراج کی تصدیق کریں، پھر دوسرا WAN کھینچیں اور دیکھیں کہ آپ کے ڈیزائن کردہ دو نتائج میں سے کون سا واقعی ہوتا ہے۔ IPv6 کو اپنا جدول، قاعدہ اور ترجمہ چاہیے؛ اوپر والا IPv4 قاعدہ اس کے بارے میں کچھ نہیں کہتا۔