pfSense پر OpenVPN کی تین قسم کی ناکامی کی منتقلی، تین میکانزم

pfSense پر „OpenVPN failover“ کم از کم تین غیر متعلق ڈیزائنوں پر محیط ہے اور ان میں سے ہر ایک مختلف میکانزم مانگتا ہے۔ بیک اپ انٹرنیٹ لنک پر ٹنل کو زندہ رکھنا، کسی دوسرے سرور سے دوبارہ جڑنا اور LAN ٹریفک کو کسی اور قائم شدہ ٹنل میں موڑنا ایک ہی خصوصیت کی مختلف صورتیں نہیں۔ گیٹ وے گروپ بنانے سے پہلے وہ خرابی منتخب کریں جس کے خلاف آپ دفاع کر رہے ہیں۔ جو گروپ ان میں سے ایک کو ٹھیک کرتا ہے وہ باقی دو کے لیے کچھ نہیں کرتا۔

گروپ بنانے سے پہلے خرابی کا نام لیں

وہ جملہ لکھیں جو آپ وقفے کے دوران درست دیکھنا چاہتے ہیں۔ „ٹنل بیک اپ WAN کے ذریعے دوبارہ جڑتا ہے“ اور „برانچ اب بھی دوسری ٹنل کے ذریعے ایپلیکیشن تک پہنچتی ہے“ مختلف جملے ہیں۔ صرف پہلا ٹرانسپورٹ سے متعلق ہے۔

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

مقامی WAN: ٹرانسپورٹ منتقل کریں

pfSense کے OpenVPN کلائنٹ کے لیے معاون کثیر-WAN ترتیب ایک مناسب گیٹ وے گروپ کو اس انٹرفیس کے طور پر منتخب کرتی ہے جس سے کلائنٹ جڑتا ہے۔ یہی وہ چیز ہے جو بیرونی کنکشن کو بنیادی لنک ناکام ہونے پر بیک اپ لنک سے نکلنے دیتی ہے۔ بذات خود یہ اندرونی ٹریفک کی روٹنگ نہیں بدلتا۔

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

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

دور دراز اینڈ پوائنٹ: دوسرا سرور

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

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

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

ٹنل کا راستہ: دوسرا اخراج منتخب کریں

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

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

اگر تقاضا یہ ہے کہ موجودہ سیشنز زندہ رہیں تو یہ صاف کہیں۔ زیادہ تر نفاذ زندہ بہاؤ کو ٹنلوں کے درمیان منتقل نہیں کرتے، اور ایسے ڈیزائن کرنا گویا وہ کرتے ہیں ایسی منتقلی دیتا ہے جو نقشے میں درست لگتی ہے اور عملاً ہر کھلا کنکشن گرا دیتی ہے۔

مانیٹرز، NAT اور fail-closed قاعدہ

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

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

پھر فیصلہ کریں کہ اس ٹریفک کا کیا ہو جو کبھی WAN استعمال نہیں کر سکتی۔ pfSense کا ان قواعد کے لیے متعین رویہ ہے جن کا منتخب کردہ گیٹ وے گر گیا ہو، اور بعد میں آنے والا وسیع اجازت کا قاعدہ یا ڈیفالٹ راستہ آپ کا ارادہ باطل کر سکتا ہے۔ مسدود نتیجہ تقاضے کے طور پر لکھیں، پھر راستہ بند کر کے اس کی تصدیق کریں۔

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