دو اسٹیک VPN پولز: strongSwan میں دونوں خاندانوں کو مخاطب کرنا

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

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

اندر دو خاندان، باہر ایک راستہ

بیرونی کنکشن UDP پر IKE ہے، اور اسے کلائنٹ جہاں بھی ہو وہاں سے ایک قابل رسائی پتہ خاندان چاہیے۔ اندرونی IPv6 پتے کے لیے IPv6 کے قابل ISP کی ضرورت نہیں، کیونکہ اندرونی پیکٹ بیرونی پیکٹ کے اندر پے لوڈ ہے۔ بہت سی کارآمد تعیناتیاں IPv6 پریفکسز کو صرف IPv4 والے اپ لنک سے گزارتی ہیں۔

بیرونی راستہ درحقیقت رسائی اور NAT عبور کو محدود کرتا ہے۔ اگر گیٹ وے صرف IPv4 پتہ اعلان کرے، تو صرف IPv6 والے نیٹ ورک پر کلائنٹ آپ کتنے ہی پولز کنفیگر کریں بالکل بھی جڑ نہیں سکتا۔ بیرونی خاندان کا فیصلہ اپنی کلائنٹ آبادی کی بنیاد پر کریں، اندرونی پتہ منصوبے کی بنیاد پر نہیں۔

ہر خاندان میں کلائنٹ کو پتہ دیں

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

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

یہ vips قدر ہر خاندان سے ایک پتہ مانگتی ہے، اور پولز کی فہرست طے کرتی ہے کہ وہ پتے کہاں سے آتے ہیں۔strongSwan کی مجازی IP سے متعلق دستاویزات متعدد درخواستوں اور پول مختص کرنے کا احاطہ کرتی ہیں، بشمول یہ نکتہ کہ مخصوص پتہ مانگنے والا کلائنٹ محض ایک ترجیح ظاہر کرتا ہے جسے جواب دینے والا منسوخ کر سکتا ہے۔ ایسا رسائی قاعدہ نہ بنائیں جو یہ فرض کرے کہ کلائنٹ کو ہمیشہ وہی قدر ملتی ہے۔

مثال کی نقل کرنے کے بجائے اپنا منفرد مقامی پریفکس بنائیں۔ دو تنظیمیں جو دونوں fd42::/16 اسے نافذ کریں، پہلی بار ایک دوسرے سے جڑتے وقت تصادم دریافت کریں گی، اور اس کی تشخیص خوشگوار نہیں۔

منتخب کنندگان منزلوں کی وضاحت کرتے ہیں، ذرائع کی نہیں

چائلڈ SA کے مقامی ٹریفک منتخب کنندگان بتاتے ہیں کہ گیٹ وے کے پیچھے کون سے محفوظ نیٹ ورک ہیں، اور دور کے منتخب کنندگان بیان کرتے ہیں کہ کلائنٹ بطور ذریعہ کیا استعمال کر سکتا ہے۔ مجازی پول کا پتہ اسی پالیسی کے ذریعہ کی طرف سے ہے؛ اسے منزلوں کی فہرست میں رکھنا کنفیگریشن کی عام غلط قرأت ہے۔

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

پولز اور سروس پریفکسز کو اپنے پتہ منصوبے کے الگ بلاکس میں رکھیں۔ جب وہ اوورلیپ ہوں، تو محفوظ ہوسٹ تک پہنچنے والا راستہ پول کے پتے سے مل کر ٹنل میں غائب ہو سکتا ہے۔

DNS اور جواب کا راستہ طے کرتے ہیں کہ یہ مکمل لگتا ہے یا نہیں

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

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

مکمل کہنے سے پہلے دونوں خاندانوں کی تصدیق کریں

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

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

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

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