سائٹ VPN پتوں کو دوبارہ نمبر دیے بغیر ISP تبدیل کریں

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

دو پتہ منصوبے جو الگ الگ حرکت کرتے ہیں

اندرونی منصوبہ وہ نجی پتے بیان کرتا ہے جو ایپلیکیشنز استعمال کرتی ہیں: 10.55.8.20 پر برانچ سرور، مرکزی دفتر کا پریفکس جو اُس تک روٹ کرتا ہے، اور واپسی کا راستہ۔ بیرونی منصوبہ بتاتا ہے کہ دو گیٹ ویز ایک دوسرے تک کیسے پہنچتے ہیں: پیر پتے، سننے کی پورٹیں اور انٹرنیٹ کے پار راستہ۔

فراہم کنندہ کی تبدیلی بیرونی منصوبے کو چھوتی ہے۔ بذاتِ خود یہ اندرونی منصوبے کی تبدیلی کا تقاضا نہیں کرتی۔

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

بیرونی ٹنل اندرونی گفتگو اٹھائے رکھتا ہے

گیٹ وے سے گیٹ وے ٹنل میں بیرونی IP ہیڈر دونوں گیٹ ویز کو مخاطب کرتا ہے۔ اندرونی ہیڈر پھر بھی اصل ایپلیکیشن اینڈ پوائنٹس کے نام لیتا ہے۔ RFC 7296 کی گیٹ وے سے گیٹ وے وضاحت اِسے معمول کی روٹنگ سمجھتی ہے جو ٹریفک ٹنل اینڈ پوائنٹس سے گزار کر پہنچاتی ہے۔

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

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

فراہم کنندہ کی منتقلی کا پھر بھی چیک لسٹ ہے

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

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

کسی دوسری منسلک سائٹ کے ساتھ پتوں کا اوورلیپ الگ منصوبہ بندی کا مسئلہ ہے۔ فراہم کنندہ کی تبدیلی اُسے پیدا نہیں کرتی، مگر منتقلی عموماً وہی وقت ہوتا ہے جب یہ سامنے آتا ہے۔

کیا نہیں بچتا: عوامی ماخذ اور سیشنز

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

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

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

منتقلی کی چار جانچوں سے تصدیق کریں

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

لینکس گیٹ وے پر یہ تین اُس فہرست کے وسط کو ڈھانپتے ہیں:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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