دوسرا WAN VPN اندراج ناکام ہوتا ہے جبکہ بنیادی اب بھی کام کرتا ہے

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

ہر WAN کو اپنا اندراجی معاہدہ درکار ہے

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

آلہ اور اس کی ریلیز کو بھی یہ ترتیب سپورٹ کرنی چاہیے۔ DNS ریکارڈ دوسرے انٹرفیس پر خدمت نہیں کھول سکتا، اور بہت سے پلیٹ فارمز پر سننے والا ڈیوائس کے بجائے پتے کے مطابق ترتیب دیا جاتا ہے۔ ASA پر انٹرفیس پر مبنی IPsec کرپٹو میپ اور سرنگ گروپس کو بیرونی انٹرفیس سے باندھتا ہے، اس لیے دوسرے اپ لنک کو وہاں پالیسی چاہیے جہاں وہ پیکٹ واقعی پہنچتے ہیں۔ راستے پر مبنی ڈیزائن مختلف رویہ رکھتے ہیں: سننے والا ہر پتے یا ایک نامزد پتے سے جڑ سکتا ہے، اور یہ انتخاب طے کرتا ہے کہ ISP B بالکل جواب دے سکتا ہے یا نہیں۔

یقینی بنائیں کہ دوسرا WAN واقعی جواب دیتا ہے

دونوں سرکٹوں کے باہر سے جانچیں، گیٹ وے کے پیچھے کی مشین سے نہیں، اور وہی درست نام جانچیں جو کلائنٹ پروفائل استعمال کرتا ہے۔ TLS سننے والے کے لیے تیز جانچ openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts ہے جو آپ کے نیٹ ورک سے باہر میزبان پر چلائی جاتی ہے۔ آپ کو مکمل مصافحہ چاہیے جس کا سلسلہ پروفائل کے نام سے میل کھائے، صرف وہ TCP پورٹ نہیں جو رابطہ قبول کرے۔

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

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

جواب کا پیچھا کریں، صرف درخواست کا نہیں

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

دوسرے اندراج سے ماخذ والی ٹریفک کے لیے راستہ بندی کا فیصلہ جانچیں۔ جواب اسی انٹرفیس سے باہر جانا چاہیے جہاں سے درخواست آئی، یا کم از کم ایسا پتہ لے کر جانا چاہیے جسے دور کا فریق اس راستے کا حصہ مان کر قبول کرے۔ پالیسی راستہ بندی والے پلیٹ فارمز پر اس کا مطلب ہے آنے والے انٹرفیس یا ترجمہ شدہ ماخذ پر قفل شدہ قاعدہ، اور ہر بیرونی انٹرفیس سے بندھا ترجمہ بیان۔ کلائنٹ جڑتے وقت دونوں انٹرفیسوں پر ایک ساتھ کیپچر کریں؛ ISP B پر آنے والا SYN اور ISP A سے جانے والا SYN-ACK ایک ہی دور میں سوال طے کر دیتے ہیں۔

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

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

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

دو فراہم کنندگان پر ایک پتہ مختلف مصنوع ہے

ایک ہی عوامی پتہ دونوں سرکٹوں سے قابلِ رسائی رکھنا راستہ بندی کی خدمت ہے، VPN میں کوئی چیک باکس نہیں۔ اسے ایسی پتہ جگہ چاہیے جو دونوں فراہم کنندگان لے جانے کو تیار ہوں، ان کے نیٹ ورک قبول کریں ایسے انداز میں اعلان شدہ، اور یہی وہ چیز ہے جو فراہم کنندہ سے آزاد جگہ اور BGP والی ملٹی ہومنگ دیتی ہے۔ ISP A کا پتہ ISP B کے انٹرفیس کو دینے سے آپ وہاں نہیں پہنچتے؛ پیکٹ ایسے نیٹ ورک تک پہنچتا ہے جس نے وہ سابقہ کبھی اعلان نہیں کیا اور اوپر کی جانب پھینک دیا جاتا ہے۔

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

آگے کیا جانچنا ہے

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

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