4G پر برانچ VPN: IP بدلنے پر شناخت مستحکم رکھیں
موبائل برانچ اپنا پتہ بدلتی ہے مگر یہ نہیں بدلتی کہ وہ کون ہے۔ ہب پر IKE شناخت پن کریں، برانچ کو آغاز کرنے والا رکھیں، پھر پتے کی حقیقی تبدیلی آزمائیں۔
برانچ سے ہی شروع کریں، 4G راؤٹر کے WAN اسٹیٹس صفحے پر۔ اگر آپ کو نظر آنے والا پتہ عوامی رینج کے بجائے آپریٹر کی نجی رینج میں ہے، تو اس باکس پر کوئی پورٹ فارورڈنگ ہب کو کبھی اندر ڈائل کرنے نہیں دے گی، اور ٹنل برانچ سے باہر کی طرف بنانی ہوگی۔ یہی ایک مشاہدہ ڈیزائن طے کرتا ہے۔ باقی کام یہ یقینی بنانا ہے کہ ہب برانچ کو ہر چند گھنٹوں میں بدلنے والے پتے سے بہتر کسی چیز سے پہچانے۔
ٹنل کہاں سے شروع ہونا چاہیے
پتے کو اس مشترکہ پتہ فضا کے سامنے جانچیں جو آپریٹر اپنے NAT کے لیے استعمال کرتے ہیں، 100.64.0.0/10، اور عام نجی رینجوں کے سامنے بھی۔ موبائل اپ لنک پر ان میں سے کوئی دیکھنا عام طور پر یہ مطلب رکھتا ہے کہ آپریٹر سطح کا NAT برانچ اور انٹرنیٹ کے درمیان ہے، اور آنے والے کنکشن کسی بھی ایسی قیمت پر دستیاب نہیں جو برانچ ادا کر سکے۔ جب WAN پتہ عوامی ہو مگر بدلتا ہو، تو آپ کو دوسرا، آسان مسئلہ ہے۔
ڈائنامک DNS صرف دوسری صورت میں مدد کرتا ہے۔ یہ بدلتے عوامی پتے کو ڈائل کرنے کے لیے مستحکم نام دیتا ہے، اور ایسی میپنگ نہیں بنا سکتا جو آپریٹر نے کبھی فراہم نہ کی ہو۔ عوامی صورت کے لیے اسے ترتیب دینا پھر بھی مناسب ہے، کیونکہ یہ دوبارہ نمبر کاری میں واحد ہاتھ سے کیا جانے والا مرحلہ ہٹا دیتا ہے۔ جس چیز میں یہ تبدیل نہیں ہونا چاہیے وہ ایسی برانچ کا جواب ہے جسے آپریٹر نے کبھی قابل رسائی نہیں بنایا۔
جس پتے پر آپ ڈائل کرتے ہیں اور جس شناخت کو ملاتے ہیں، انھیں الگ کریں
ہب کو تلاش کیے جانے کے لیے کوئی مستحکم چیز چاہیے، منظور شدہ مقررہ پتہ یا برقرار رکھا گیا ہوسٹ نام۔ برانچ کو پہچانے جانے کا مستحکم طریقہ چاہیے، اور IKEv2 میں وہی شناختی پے لوڈ ہے جو وہ توثیق کے دوران پیش کرتی ہے، اس ماخذ پتے سے آزاد جو اس کے پیکٹ اتفاقاً اٹھائے چلتے ہیں۔ @branch-a.vpn.example جیسی سٹرنگ اس شناخت کے طور پر کام کرتی ہے، چاہے موبائل پتہ ہر گھنٹے بدلے۔
اس سٹرنگ کو پالیسی سے ملایا جاتا ہے، DNS کے ذریعے حل نہیں کیا جاتا، اس لیے ٹنل کے قیام پر کسی تلاش کی توقع نہ رکھیں۔ ہب کی ترتیب کو متوقع شناخت کا واضح طور پر نام دینا چاہیے، اور سرٹیفکیٹ توثیق کے ساتھ شناخت کو اس سے بھی میل کھانا چاہیے جو سرٹیفکیٹ حقیقت میں دعوی کرتا ہے۔
محض اس لیے کوئی بھی شناخت قبول کرنا کہ ماخذ پتہ معقول لگتا ہے، وہ ناکامی کی روش ہے جس سے بچنا چاہیے۔ جواب دینے والے کی طرف اس کا مطلب ہے شناخت وائلڈ کارڈ اور مشترکہ راز کے ساتھ کوئی بھی ساتھی قبول کرنا، جو آلے کے بجائے سٹرنگ کی توثیق کرتا ہے۔
ہب کی طرف کو نامزد ساتھی کے طور پر لکھیں
strongSwan کی اصطلاحات میں جواب دینے والا فریق right=%any والا کنکشن ہے، جو کسی بھی ماخذ پتے سے ساتھی قبول کرتا ہے، نیز [email protected]، جو پن کرتا ہے کہ وہ ساتھی اپنے آپ کو کیا کہے۔ برانچ کے LAN کے لیے rightsubnet=10.20.0.0/16، کنکشن کے بغیر ڈائل لوڈ ہونے کے لیے auto=add، زندگی کے لیے dpd_delay=30s، اور پتے کی تبدیلی کو نیا ساتھی سمجھنے کے بجائے جذب کرنے کے لیے mobike=yes شامل کریں۔
دوسرے فروش وہی اشیا مختلف ناموں کے تحت بیان کرتے ہیں، عام طور پر شناختی فیلڈ اور محفوظ ذیلی نیٹ فیلڈ والی ڈائنامک یا برانچ آفس ساتھی قسم۔ دونوں بھریں؛ عام ڈائنامک چیک باکس مطابقت کا منصوبہ نہیں ہے۔
برانچ کو آغاز کرنے والا رکھیں
برانچ پر آئینے کی تصویر لاگو ہوتی ہے: مقامی موبائل پتہ جیسا ابھی ہے ویسے ہی استعمال ہونے کے لیے left=%defaultroute، شناخت پیش کرنے کے لیے [email protected]، مستحکم ہب نام کے لیے right=hub.example.com، اور بغیر کسی انسان کے ٹنل کے اوپر آنے کے لیے auto=start۔ جب موبائل لنک دوبارہ جڑتا ہے، برانچ پھر آغاز کرتی ہے اور ہب وہی شناخت اسی پالیسی شے کے سامنے ملاتا ہے۔
دونوں طرف UDP 500 پر IKE، UDP 4500 پر NAT گزر، اور اس کے بعد آنے والا انکیپسولیٹڈ ESP اجازت دیں۔ پھر انھیں اجازت یافتہ ہی رہنے دیں: صرف دفتری اوقات میں کھلنے والا قاعدہ رک رک کر چلنے والی ٹنل جیسا دکھے گا۔
پتے کی تبدیلی آزمائیں، صرف پہلا ہینڈ شیک نہیں
ٹنل اوپر لائیں، اس کی تصدیق کریں، پھر ایک منٹ کے لیے موبائل ڈیٹا یا ہوائی جہاز موڈ ٹوگل کر کے برانچ کو نئے پتے پر مجبور کریں۔ ہب پر حفاظتی انجمنوں کی فہرست دیکھیں اور جانچیں کہ ساتھی کا پتہ بدلا جبکہ شناخت نہیں بدلی۔ ایسی ٹنل جو صرف آپریٹر کی پہلی دوبارہ تقسیم تک چلے، اسے بالکل آزمایا ہی نہیں گیا۔
پھر محفوظ ذیلی نیٹ الگ الگ جانچیں۔ قائم شدہ SA کہتا ہے کہ ساتھیوں نے توثیق کی؛ یہ نہیں کہتا کہ ہب کے پاس برانچ کے LAN تک راستہ ہے یا برانچ ہب کی طرف سے ٹریفک قبول کرتی ہے۔ روٹنگ جدول اور فائر وال پالیسی الگ الگ پڑھیں، پھر ping گیٹ وے سے نہیں بلکہ کسی ہوسٹ سے بھیجیں، کیونکہ گیٹ وے کسی بھی نیٹ ورک میں سب سے کم نمائندگی کرنے والا آلہ ہے۔
مستحکم شناخت برانچ کو ایسی پالیسی شے بنا دیتی ہے جسے ہب نام دے سکے۔ یہ آپریٹر NAT پتے کو قابل رسائی نہیں بناتی، اور اپنے آپ میں تنظیم کے باقی حصے کو برانچ تک رسائی نہیں دیتی۔