strongSwan برائے EC2: VPC کو کام کا بوجھ روٹ کرنے دیں

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

پہلے چار پتے لکھ لیں

نیچے دیا گیا ہر مرحلہ انہی کی طرف اشارہ کرتا ہے، اس لیے روٹنگ ٹیبل کو چھونے سے پہلے انہیں اپنے اکاؤنٹ کے لیے بھر دیں۔

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

مثال ایک منظور شدہ، فعال پالیسی پر مبنی IPsec کنکشن اور ماخذ کو محفوظ رکھنے والے بہاؤ کو فرض کرتی ہے۔ یہ NAT والا ریموٹ ایکسس کلائنٹ نہیں ہے جو ایک مختص پتہ مستعار لیتا ہے، اور یہی فرق طے کرتا ہے کہ سلیکٹرز تبدیل کرنے ہیں یا نہیں۔

مرحلہ 1: ورک لوڈ کی ذیلی نیٹ کو راستہ دیں

وہ روٹنگ ٹیبل جو واقعتاً ورک لوڈ کی ذیلی نیٹ سے منسلک ہے، اسے دور دراز پریفکس کے لیے ایسا راستہ چاہیے جو گیٹ وے کے نیٹ ورک انٹرفیس کی طرف اشارہ کرے۔ مثال کے اندر نصب مہمان راستہ اس AWS روٹنگ ٹیبل میں اندراج نہیں ہے اور strongSwan کی کوئی مقدار ایسا نہیں بنائے گی۔

AWS کی آلے کے ذریعے روٹنگ کی رہنمائی نیٹ ورک انٹرفیس کے اہداف اور فارورڈ کرنے والی مثال کی ماخذ/منزل جانچ کی ضرورت بیان کرتی ہے۔ یہ جانچ تبدیلی گیٹ وے کے کردار تک محدود رکھیں اور عام ایپلیکیشن مثالوں کو کھلی چھوڑ دیں۔

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

مرحلہ 2: مہمان پر فارورڈنگ فعال کریں

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

سیکیورٹی گروپس وہ جگہ ہیں جہاں یہ مرحلہ عام طور پر رک جاتا ہے۔ درمیانی آلہ مثالوں کے درمیان براہ راست رابطے کے سیکیورٹی گروپ حوالہ جاتی رویے کا وارث نہیں ہوتا، اس لیے منظم Client VPN کی مثال سے نقل کیا گیا قاعدہ کبھی نہیں مل سکتا۔ اصل راستے پر سیکیورٹی گروپ اور ذیلی نیٹ ACL دونوں سمتوں میں جانچیں۔

مرحلہ 3: سلیکٹرز کو حقیقی ماخذوں تک وسیع کریں

AWS کی طرف صرف 10.60.1.10/32 کا احاطہ کرنے والی پالیسی گیٹ وے سے شروع ہونے والی کامیابی کی وضاحت کرتی ہے بغیر 10.60.2.20 کا احاطہ کیے۔ دور دراز منزل کی طرف راستہ ٹریفک سلیکٹر کو وسیع نہیں کرتا، اور یہ اسی حیرت کا دوسرا نصف ہے۔

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

اگر طے شدہ ڈیزائن پورے VPC کی حفاظت کرتا ہے تو دونوں فریقوں کو 10.60.0.0/16 اور 10.90.0.0/24 قبول کرنے ہوں گے۔ اگر یہ ایک ورک لوڈ کی حفاظت کرتا ہے تو جان بوجھ کر وہ تنگ پریفکس استعمال کریں۔ بہرحال، نصب شدہ CHILD-SA پالیسی جانچیں، کیونکہ آپ کی ترمیم کردہ ترتیب اور وہ فریق جس نے اسے مختلف طور پر تنگ کیا، ایک ہی معاہدہ نہیں ہیں۔

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

مرحلہ 4: تصدیق کریں، پھر ضرورت ہو تو واپس کریں

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

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

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