متعدد OpenVPN ریموٹ: failover فہرست، لنک بونڈنگ نہیں

ایک پروفائل میں دو ریموٹ لائنیں دوسری لین جیسی لگتی ہیں؛ دراصل وہ دوسری کوشش ہیں۔ جب پہلا endpoint جواب دینا چھوڑ دیتا ہے تو کلائنٹ آگے بڑھ جاتا ہے اور سیشن وسیع نہیں ہوتا۔ فہرست کو شروع ہی میں failover کہیں، ورنہ آپ غلط نوب گھمائیں گے۔

ریموٹ فہرست آپ کو کیا دیتی ہے

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

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

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

ایک endpoint کے ساتھ ترتیبات رکھنے والے بلاک

عام remote لائن ایک پتہ لے جاتی ہے، اور کبھی پورٹ اور پروٹوکول بھی۔ جب endpoint کو پراکسی یا ایسی ٹرانسپورٹ درکار ہو جو باقی فائل استعمال نہیں کرتی، تو وہ ترتیبات ایک کنکشن بلاک میں رکھیں جو انہیں اس کے ساتھ رکھتا ہے۔ اِن لائن بلاک ایک .ovpn فائل میں بھی کام کرتے ہیں، اور زیادہ تر پروفائل اسی طرح آتے ہیں۔

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

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

دوبارہ کوشش کی ترتیب اور remote-random کی قیمت

ترتیب اہم ہے کیونکہ ہر مردہ اندراج اگلی کوشش سے پہلے وقت لیتا ہے۔ مطلوبہ endpoint پہلے رکھیں اور باقی کو ترتیب شدہ متبادل سمجھیں۔

remote-random ابتدائی ترتیب خلط ملط کرتا ہے، جو بوجھ مساوی سرورز پر پھیلاتا ہے اور جب ایک endpoint واضح طور پر بنیادی ہو تو الٹا پڑتا ہے۔ بہرحال، کلائنٹ نے جو endpoint چنا اسے لاگ کریں؛ کنکشن سست محسوس ہونے پر پروفائل کا نام کچھ نہیں کہتا۔ تفصیلی لاگ سے لنک لائن grep کرنے پر معلوم ہوتا ہے کہ سیشن کہاں اترا۔

آپریٹرز کو ملانا اعتماد کے بیان کو توڑتا ہے

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

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

قیاس کرنے کے بجائے ہر اندراج آزمائیں

منظور شدہ پروفائل اپ ڈیٹ کے بعد ہر ضروری endpoint سے جان بوجھ کر جڑیں اور تصدیق کریں کہ کون سی ٹرانسپورٹ اٹھی۔ تفصیلی رن اسے نمایاں کرتی ہے۔ openvpn --config office.ovpn --verb 4 شروع کریں اور متوقع پتے کے لیے لنک لائن پڑھیں۔ پھر سرنگ کے پیچھے کے وسائل جانچیں؛ ایک اندراج ہینڈ شیک مکمل کر کے بھی آپ کو کہیں روٹ نہیں کر سکتا۔

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

آپریٹر فہرست بدلے تو ہر بار اسے دوبارہ جانچیں۔ درآمد شدہ مجموعہ صرف اس وقت کارآمد ہے جب اس کے اندراجات موجود ہوں اور وہ ٹرانسپورٹ بولیں جو آپ کے بلاک بیان کرتے ہیں۔ OpenVPN 2.6 دستی کتاب یہاں remote، connection اور random-order ہدایات کا احاطہ کرتی ہے، اور نحو مشکوک ہونے پر جانچنے والا نسخہ یہی ہے۔