دو فعال IPsec ٹنلوں کو اب بھی واپسی راستے کا منصوبہ درکار ہے

ایک سائٹ کے ورک اسٹیشن پر ٹرمینل کھولیں اور دوسری سائٹ کے سرور سے جڑیں۔ اُس واحد TCP گفتگو کو اب دو کی بجائے چار گیٹ وے عبور کرنے ہیں، اور دلچسپ بات یہ نہیں کہ یہ کسی اچھے دن کام کرتی ہے۔ دلچسپ بات یہ ہے کہ آگے کی سمت نے گیٹ وے کی کون سی جوڑی چنی، جواب کون سی جوڑی چنتا ہے، اور یہ ہوتے ہوئے بہاؤ کی حالت کون رکھتا ہے۔ روٹنگ جدول میں کوئی چیز یہ آپ کے لیے طے نہیں کرتی۔

راستہ کھینچنے سے پہلے چار گیٹ وے کھینچیں

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

وہی جدول ڈیزائن ہے۔ اُس کے بعد سب کچھ یہ سوال ہے کہ آیا آلات جدول سے متفق ہیں۔

آگے کا راستہ کیسے چنا جاتا ہے

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

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

واپسی راستے کو واقعی کیا درکار ہے

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

نافذ شدہ دو طرفہ رویے کی تصدیق کریں، یا ایسی واضح پالیسی لکھیں جو مطلوبہ حدود کو ہم آہنگ رکھے۔ یہاں کا اندازہ خلل کے دوران اُن لوگوں سے کھلتا ہے جو اِس سے لطف اندوز نہیں ہو رہے۔

جہاں ترجمہ آپ کی طرف سے فیصلہ کرتا ہے

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

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

قبولیت کو ترتیب سے طے کریں

اِس ترتیب سے جانچیں اور ہر مرحلے پر پتے درج کریں: راستہ A پر نیا کنکشن اور اُس کا جوابی راستہ، راستہ B پر بھی وہی، پھر ایک فراہم کنندہ کا نقصان، پھر بحالی۔ ہر نتیجے کے لیے نوٹ کریں کہ کون سے قائم شدہ بہاؤ ہلے، کنہیں دوبارہ جڑنا پڑا اور نئے بہاؤ بعد میں کہاں گئے۔ پہلے متوقع قدر لکھیں، پھر اُس کا کیپچر سے موازنہ کریں۔ دو قائم شدہ ٹنل اِن میں سے کچھ بھی ثابت نہیں کرتیں۔

ڈیزائن اُس وقت مکمل ہوتا ہے جب آپ کا لکھا جدول کیپچر کے دکھائے سے میل کھائے، اُس وقت نہیں جب دونوں ٹنل چل رہی ہوں۔