strongSwan سے AWS Site-to-Site تک: Child SA کچھ بھی کیوں نہیں چنتا

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

AWS کے ناموں کو strongSwan کی اصطلاحات میں بدلیں

AWS رابطے کو گاہک کی طرف سے بیان کرتا ہے: گاہک گیٹ وے کا پتہ اور مقامی CIDR آپ کے ہیں، اور دور CIDR VPC کا ہے۔ strongSwan دونوں سروں کو left اور right کہتا ہے، آپ کا سابقہ leftsubnet میں اور VPC کا سابقہ rightsubnet میں ہوتا ہے۔ ایک جوڑا الٹ دینے سے ایسی ٹنل بنتی ہے جو غلط ٹریفک پر بات چیت کر کے اسے چنتی ہے۔

AWS جو کنفیگریشن رابطے کے لیے بناتا ہے اسے ڈاؤن لوڈ کریں اور ٹنل کے پتوں اور سابقوں سمیت اسی رابطے کا حوالہ سمجھیں۔ بناتے وقت دونوں CIDR خانے خالی چھوڑنے پر سروس ہر طرف 0.0.0.0/0 ڈیفالٹ استعمال کرتی ہے۔ تنگ سابقے والا راؤٹر پھر کبھی اس سے نہیں ملے گا، اس لیے خانے بھریں یا چنندہ جان بوجھ کر وسیع کریں۔

یہاں کا عدم توازن راؤٹنگ کی ناکامی جیسا لگتا ہے اور ہے نہیں۔

وہ پتہ مستقل کریں جو AWS واقعی دیکھتا ہے

NAT کے پیچھے راؤٹر ایسے انٹرفیس سے IKE بھیج سکتا ہے جسے سامنے والے فریق نے کبھی نہیں جانا۔ AWS میں درج گیٹ وے پتہ وہی ہونا چاہیے جو AWS نیٹ ورک پر دیکھتا ہے، اور راؤٹر کو اپنے ڈیفالٹ راستے کی بجائے اسی مقامی پتے پر مستقل کرنا چاہیے۔

conn %default
    local_addrs = 203.0.113.10

strongSwan میں local_addrs IKE کے لیے ماخذ پتہ چنتا ہے، اور پرانی OpenSwan کنفیگریشنز اسی خیال کو left لکھتی ہیں۔ اسے عوامی پتے والے انٹرفیس کی طرف موڑیں، پھر NAT ڈیوائس پر ہی تصدیق کریں کہ UDP 500 اور 4500 اس ہوسٹ تک پہنچتے ہیں، کیونکہ پچھلے راؤٹر سے بچا ہوا اصول انہیں خاموشی سے گرا دیتا ہے۔ درست چنندہ جوڑا غلط ماخذ پتے کے ساتھ بھی ناکام ہوتا ہے، اور لاگ الزام تجویز پر ڈالتا ہے۔ یہی گمراہی سبب ہے کہ ماخذ پتہ اپنی الگ جانچ کا حقدار ہے۔

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

مرحلہ 1 اور مرحلہ 2 کو الگ الگ سنبھالیں

AWS IKE اور ESP کے اختیارات الگ فہرستوں کے طور پر دکھاتا ہے۔ دونوں فریق جو IKE سیٹ قبول کرتے ہیں وہ ESP تجویز کے بارے میں کچھ نہیں کہتا، کیونکہ دونوں فہرستیں آزاد ہیں۔ دونوں کو بنی ہوئی کنفیگریشن سے پڑھیں اور ایک ایک کر کے موازنہ کریں۔

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

نحو مختلف عمل درآمد کے درمیان سفر نہیں کرتی۔ OpenSwan میں چلنے والا جوڑا، مثلاً phase2alg=aes_gcm کے ساتھ ike=aes256-sha1;modp1024، strongSwan کے esp= اور ike= کی شکل میں ترجمہ کرنا پڑتا ہے، اور الگورتھم کے نام مختلف ہیں۔ چونکہ GCM انکرپٹ کرتے ہوئے تصدیق کرتا ہے، اسے الگ سالمیت کی تبدیلی درکار نہیں، SHA کے ساتھ جڑے CBC سیٹ کے برعکس۔ ایک ڈیمن سے دوسرے میں بغیر ترجمہ چسپاں کی گئی مرحلہ 2 کی سطر چنندہ کے عدم توازن جیسی پڑھی جانے والی مستردگی پیدا کرتی ہے۔

ٹنل کے اشارے کی نہیں، چائلڈ ایسوسی ایشن کی جانچ کریں

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

ipsec statusall

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

مقامی سابقے کے اندر کے ہوسٹ سے VPC سابقے کے اندر کے ہوسٹ تک جانچ کریں اور واپسی راستہ نیز AWS کی طرف کا کوئی بھی سیکیورٹی گروپ یا نیٹ ورک ACL دیکھیں۔ درست چنندہ پیکٹ کو بعد میں گرائے جانے سے نہیں بچاتے۔

چنندہ کے مطابق ہونے کے بعد بھی ناکام ہو تو

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

دوسری تجویز بدلنے سے پہلے ہر طرف ایک آنے والا اور ایک جانے والا پیکٹ لاگ کریں۔

ٹکٹ میں چنندہ، مرحلہ 1 اور مرحلہ 2 کی تجاویز اور ماخذ پتہ درج کریں۔ یہ چار قدریں کال کے بغیر زیادہ تر site-to-site ناکامیوں کی وضاحت کرتی ہیں۔