XFRM انٹرفیس کے ساتھ روٹ پر مبنی IPsec کیسے کام کرتا ہے

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

ڈیوائس کیا ہے اور کیا نہیں

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

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

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

درست ترتیب میں ایک بنائیں

بیرونی ڈیوائس اور اس نمبر سے شروع کریں جو آپ ڈیمون کنفیگریشن میں بھی رکھیں گے۔ مثال بیرونی انٹرفیس کے طور پر eth0 اور شناخت کے طور پر 42 استعمال کرتی ہے، یہ پتے آپ کو اپنے پتوں سے بدلنے چاہئیں۔

ڈیوائس اوپر کریں، پھر VPN کنفیگریشن کو چھونے سے پہلے کرنل کے ریکارڈ کردہ شناخت کی تصدیق کریں:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

IKE اور ESP کو ٹنل روٹ سے باہر رکھیں

XFRM ڈیوائس کی طرف اشارہ کرنے والا ڈیفالٹ روٹ انکیپسولیٹ پیکٹ اور ان کا اٹھایا ہوا ٹریفک دونوں پکڑ لیتا ہے۔ نتیجہ ایک لوپ ہے: گیٹ وے اپنا ESP اس ٹنل سے بھیجنے کی کوشش کرتا ہے جو ESP کو بنانی ہے۔

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

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

انکرپشن کو قصوروار ٹھہرانے سے پہلے دو جگہوں پر کاؤنٹرز جانچیں

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

دونوں پڑھیں، پھر چائلڈ ایسوسی ایشن کے بارے میں ڈیمون کا نقطہ نظر پڑھیں:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

فیصلہ کریں کہ روٹ کون نصب کرے گا

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

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

فارورڈنگ اور فائر وال کے قواعد اس پر الگ فیصلہ ہیں، کیونکہ دوسرے ہوسٹس کی ٹریفک گزرانے والے گیٹ وے کو دونوں درکار ہوتے ہیں۔ روٹ پر مبنی IPsec اس ٹریفک کو عام روٹنگ اوزاروں سے بیان کرنا آسان بناتا ہے؛ یہ پالیسی پرت کو اختیاری نہیں بناتا۔