strongSwan میں مکمل سرنگ کے لیے دونوں طرف 0.0.0.0/0 ضروری ہے

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

پہلے کلائنٹ کا سلیکٹر جانچیں

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

یہ ٹکڑا مکمل کنکشن فائل نہیں ہے، اور یہ فرض کرتا ہے کہ تصدیق، شناختیں اور مجازی پتوں کا گروپ پہلے سے تشکیل شدہ ہیں۔ کلائنٹ کا ماخذ سلیکٹر اور سرور کا مختص کردہ پتہ اب بھی میل کھانا چاہیے، ورنہ child SA ایسے دائرے کے ساتھ اٹھے گا جس کی کسی فریق نے توقع نہیں کی۔ اسے swanctl --load-all سے لوڈ کریں اور کامیابی فرض کرنے سے پہلے آؤٹ پٹ پڑھیں۔ پارس ہونے والی فائل بھی ایسے سلیکٹر کی وجہ سے مسترد ہو سکتی ہے جو دوسرے فریق کی تجویز سے نہ ملتا ہو۔

گیٹ وے کا سلیکٹر اس کی اپنی طرف جانچیں

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

پرانا ipsec.conf مختلف کلیدوں کے ساتھ بائیں اور دائیں کردار استعمال کرتا ہے، اور rightsubnet سطر swanctl قدر کا براہ راست متبادل نہیں ہے۔ دونوں نحو کو ایک دوسرے میں چپکانے کے بجائے الگ فائلوں میں رکھیں۔ انہیں ایک ڈائریکٹری میں ملانا ہی وہ طریقہ ہے جس سے کام کرنے والا کنکشن ری بوٹ کے بعد خاموشی سے واپس چلا جاتا ہے۔

فائل نہیں، طے شدہ child SA جانچیں

محفوظ ترتیب ارادے کا ثبوت ہے اور اس سے زیادہ کچھ نہیں۔ دوسرا فریق مانگی ہوئی چیز کو تنگ کر سکتا ہے، اور موجود child SA صرف اس لیے تبدیل نہیں ہوتا کہ اس کے نیچے فائل بدل گئی ہے۔ کچھ اور بدلنے سے پہلے تصدیق کریں کہ واقعی کیا نصب ہے۔

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

پہلا حکم دکھاتا ہے کہ ڈیمن نے کیا لوڈ کیا، دوسرا قائم شدہ child SA دکھاتا ہے، اور تیسرا وہ پالیسیاں جو کرنل لاگو کرے گا۔ اگر فائل 0.0.0.0/0 کہتی ہے اور فہرست ایک ذیلی نیٹ ورک دکھاتی ہے، تو گفت و شنید نے دائرہ تنگ کر دیا ہے اور فائل دوبارہ پڑھنے سے یہ واضح نہیں ہوگا۔ child روکیں، دوبارہ شروع کریں، اور تینوں آؤٹ پٹ کا دوبارہ موازنہ کریں۔ وہی تنگ دائرہ لے کر واپس آنے والا child مقامی فائل سے نہیں بلکہ دور کی طرف سے تنگ ہو رہا ہے، اور یہ مقامی ترمیم نہیں بلکہ دوسرے منتظم سے بات چیت ہے۔

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

فارورڈنگ اور واپسی کا راستہ جانچیں

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

جانچیں کہ سرنگ ابھی کیا نہیں ڈھانپتی

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

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

اوپر کی فہرست سے طے شدہ سلیکٹروں سمیت ان دو احکام سے زنجیر کی تصدیق کریں۔ اگر traceroute مقامی روٹر کو پہلا ہاپ دکھاتا ہے، تو سلیکٹر جو بھی دعویٰ کریں، ٹریفک سرنگ استعمال نہیں کر رہا۔ انٹرنیٹ رسائی صرف اس وقت مکمل ہے جب منتخب ٹریفک ڈیزائن کردہ گیٹ وے سے قبول، فارورڈ اور واپس کیا جائے۔ پروفائل میں 0.0.0.0/0 تلاش کرنا اس زنجیر کا آغاز ہے، اس کا ثبوت نہیں۔