VPN فیل اوور: جب واپسی کا راستہ پرانے ٹنل پر ہی رہے

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

پہلے دونوں سروں پر روٹ درج کریں؛ ایک سائٹ کا منظر غیر متناسب راستہ نہیں دکھا سکتا۔ وقت کے دباؤ میں سب سے زیادہ چھوڑا جانے والا مرحلہ بھی یہی ہے۔

جانچ سے پہلے دونوں سائٹس کے روٹ درج کریں

ہر محفوظ پریفکس کے لیے بنیادی روٹ، بیک اپ روٹ اور ان کے درمیان انتخاب کرنے والی ترجیح لکھیں۔ ہر VPN اینڈ پوائنٹ کے پیچھے والا LAN گیٹ وے شامل کریں، کیونکہ اینڈ پوائنٹ شاذ و نادر ہی آخری چھلانگ ہوتا ہے۔

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

یہ دونوں سائٹس پر کریں۔ ایک طرف ترجیح پانے والا اور دوسری طرف نظر انداز کیا جانے والا بیک اپ بالکل وہی عدم توازن پیدا کرتا ہے جس سے آپ بچنا چاہتے ہیں۔

ہر مرحلے میں درخواستیں اور جوابات دیکھیں

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

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

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

گیٹ وے بدلنے پر سیشن کی حالت سنبھالیں

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

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

صرف نئی درخواست نہیں، طویل سیشن رکھنے والی ایپلیکیشن بھی جانچیں۔

بنیادی راستہ بحال کریں اور فلپنگ جانچیں

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

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