سائٹ سے سائٹ VPN: کون سی سمت کو واقعی ایک قاعدہ درکار ہے؟

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

حالت والی واپسی ٹریفک تعداد بدلتی ہے

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

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

فائر وال ڈکرپٹ شدہ پیکٹ کہاں دیکھتا ہے

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

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

غیر متوازن روٹنگ مفروضہ توڑ دیتی ہے

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

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

حقیقی ماخذ پتوں کے ساتھ دونوں سمتیں جانچیں

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

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