بے تار رابطہ بیک اپ کے طور پر: روٹ شدہ تبدیلی یا ایک سیگمنٹ؟

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

طے کریں کہ رکاوٹ میں کیا بچنا چاہیے

ان ایپلیکیشنز کی فہرست بنائیں جنہیں کام جاری رکھنا ہے اور نوٹ کریں کہ وہ Layer 3 رسائی یا Layer 2 قربت پر منحصر ہیں۔ فائل شیئرنگ، ڈیٹا بیس کنکشن اور ویب سروسز عام طور پر صرف راستوں کی پرواہ کرتی ہیں؛ دریافت پروٹوکول، کچھ کلسٹر مصنوعات اور ہر وہ چیز جو ایک براڈکاسٹ ڈومین کی توقع کرتی ہے قربت کی پرواہ کرتی ہے۔ غلط قسم کی رسائی بحال کرنے والا بیک اپ ایسی سائٹ بناتا ہے جو تکنیکی طور پر جڑی ہو مگر عملاً بیکار ہو۔

وہ فہرست لکھیں اور ڈیزائن سے منسلک کریں، کیونکہ پہلے ایپلیکیشن مالک کے نئی لنک کے بارے میں سنتے ہی جواب عام طور پر سرک جاتا ہے۔

روٹ شدہ تبدیلی: دو پریفکس، ایک ترجیحی راستہ

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

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

پل شدہ تبدیلی: ایک سیگمنٹ، ایک روکنے والا راستہ

اگر قربت واقعی ضروری ہو، تو بیک اپ کو ایتھرنیٹ فریم لے جانے ہوں گے، جو روٹ شدہ IP ٹنل نہیں کرتا۔ کچھ پلیٹ فارم VPN انٹرفیس کو مقامی سیگمنٹ میں پل کرنے کی حمایت کرتے ہیں، اور وہ انٹرفیس پھر متعلقہ نتائج کے ساتھ پل کے ممبر بن جاتے ہیں۔ ایک ساتھ فارورڈ کرنے والے دو Layer 2 راستے لوپ بناتے ہیں، اس لیے ڈیزائن کو دونوں سائٹوں کو ڈھانپنے والا اسپیننگ ٹری اور اس بارے میں واضح بیان چاہیے کہ کون سا راستہ روکا جانا چاہیے۔

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

جو حد اہم ہے اس کی نگرانی کریں

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

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

بوجھ تلے دونوں سمتوں کی مشق کریں

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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