OpenVPN کا pull-filter آپ کے ارادے والے راستے سے زیادہ سے میچ کرتا ہے

آپ ایک سطر شامل کرتے ہیں تاکہ اپنا مقامی طے شدہ راستہ رکھ سکیں، اور اس کے بعد سرنگ اب اندرونی DNS سرور تک نہیں پہنچتی۔ وہ سطر pull-filter ignore "route" تھی، جس کا مطلب "اس راستے کو نظر انداز کرو" نہیں ہے۔ اس کا مطلب "ہر دھکیلا گیا اختیار پھینک دو جس کا متن ان پانچ حروف سے شروع ہوتا ہے" ہے، اور عام سرور پر اس میں راستوں کے ساتھ route-gateway، route-metric اور route-ipv6 بھی شامل ہیں۔ نیچے دی گئی چیک لسٹ وہی ہے جو میں کسی اور کے استعمال والی پروفائل کو چھونے سے پہلے چلاتا ہوں۔

فلٹر صرف دھکیلے گئے اختیارات پر لاگو ہوتا ہے

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

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

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

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

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

مطابقت ایک سابقہ ہے، اس لیے خالی جگہیں ہی سب کچھ ہیں

موازنہ تار کا سابقہ ہے، تجزیہ شدہ اختیار کا نام نہیں۔ اسی لیے "route" route-gateway 10.8.0.1، route-ipv6 2001:db8::/32 اور route-metric 100 سے مطابقت رکھتا ہے۔ آخر میں ایک خالی جگہ شامل کرنے سے یہ اس خاندان تک محدود ہو جاتا ہے جس کا آپ نے غالباً ارادہ کیا، اور مکمل سابقہ اسے مزید ایک مخصوص منزل تک محدود کرتا ہے۔

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

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

تین فعل، تین مختلف نتائج

accept، ignore اور reject ایک ہی خیال کی تین ہجے نہیں ہیں۔ وہ اس بات میں مختلف ہیں کہ کلائنٹ مطابقت کے ساتھ کیا کرتا ہے اور کسی کو اس کا علم ہوتا ہے یا نہیں۔

ignore مطابقت رکھنے والا اختیار خاموشی سے پھینک دیتا ہے، جو آپ نے جان بوجھ کر بدلی گئی ترتیب کے لیے چاہیے۔ reject اسے پھینک دیتا ہے اور کلائنٹ کو شکایت کرنے دیتا ہے، جو تب چاہیے جب اس کی عدم موجودگی بعد میں دریافت ہونے کے بجائے لاگ میں نظر آنی چاہیے۔ accept مثبت صورت ہے، تب استعمال ہوتی ہے جب آپ الگ الگ اختیارات ہٹانے کے بجائے اجازت کی فہرست بناتے ہیں۔

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

لاگو شدہ راستہ اور حل کنندہ دیکھیں، پروفائل نہیں

فائل میں درست نظر آنے والا فلٹر بھی آپ کو ایسی سرنگ کے ساتھ چھوڑ سکتا ہے جو کوئی مفید چیز روٹ نہیں کرتی۔ چلتی ہوئی نظام پر اثر جانچیں، جہاں دھکیلے گئے اختیارات پہلے ہی لاگو یا پھینکے جا چکے ہیں:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

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

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

استثنا اور اس کا مالک درج کریں

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

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

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