OpenVPN کلائنٹ بلاک قاعدہ FORWARD تک کیوں کبھی نہیں پہنچتا

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

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

پیئر پیکٹ جن دو راستوں سے جا سکتا ہے

جب اندرونی فارورڈنگ کا اختیار بند ہو، کلائنٹ A کا پیکٹ ٹنل انٹرفیس پر آتا ہے اور اس کا منزل کلائنٹ B کے مختص کردہ پتے کے اندر ہوتی ہے۔ سرور کی روٹنگ جدول اسے اسی ٹنل انٹرفیس سے واپس بھیجتی ہے، کیونکہ B کے پتے تک راستہ سرور کے پاس ہے۔ یہ میزبان سے اندر اور باہر جانے والا بہاؤ ہے، اور IPv4 فارورڈنگ راستہ اس کا جائزہ لیتا ہے۔

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

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

جب کاؤنٹر کبھی نہیں ہلتا

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

تیسری جگہ کا معاملہ ہے۔ زنجیر میں پہلے کا قاعدہ آپ کے DROP کے جائزے سے پہلے بہاؤ قبول کر سکتا ہے، اور بعد کا قاعدہ وہ ہو سکتا ہے جو نتیجہ واقعی طے کرتا ہے۔ کاؤنٹر دکھائی دیتے ہوئے زنجیر کو ترتیب سے پڑھیں، پھر دیکھیں کہ تجربہ دہرانے پر کس قاعدے کی گنتی بڑھتی ہے۔

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

ایسی حد چننا جو فلٹر کر سکے

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

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

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

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

قاعدے پر بھروسا کرنے کے بجائے تنہائی جانچنا

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

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

تنہائی وہ مشاہدہ شدہ نتیجہ ہے جو اس حد پر ملتا ہے جو واقعی بہاؤ اٹھاتی ہے۔ میزبان میں کہیں DROP قاعدہ ثبوت نہیں ہے؛ ناکام کنکشن اور اسے پیدا کرنے والے قاعدے کا ہلا ہوا کاؤنٹر ثبوت ہے۔