دفتر کے LAN پر VPN کلائنٹ ہر جواب کیوں کھو دیتا ہے
دفتر کے LAN پر اور اسی سب نیٹ کی سرنگ پر موجود لیپ ٹاپ غلط انٹرفیس سے جواب دیتا ہے۔ ڈھیلا ریورس پاتھ فلٹرنگ اس خاموشی کی وضاحت کرتا ہے۔
ایک لیپ ٹاپ ایتھرنیٹ کے ذریعے دفتر کے /24 پر بیٹھا ہے اور اسی /24 میں رہنے والے OpenVPN سرور سے بھی جڑتا ہے۔ ایک ساتھی سرنگ کے پتے پر پنگ کرتا ہے؛ درخواست واضح طور پر پہنچتی ہے، اور کچھ بھی واپس نہیں آتا۔ سرنگ کا لاگ صاف ہے اور براؤزنگ اب بھی چلتی ہے، اس لیے سرنگ غلط مشتبہ ہے۔ وصول کرنے والی مشین پر IPv4 ماخذ کی تصدیق پیکٹ کو کچھ پڑھنے سے پہلے ہی پھینک دیتی ہے۔
پھینکنا پیکٹ پڑھنے سے پہلے ہوتا ہے
ماخذ کی تصدیق ہر آنے والے پیکٹ کے بارے میں ایک سوال پوچھتی ہے: اگر یہ ہوسٹ اُس ماخذ کو جواب دے، تو کیا جواب اسی انٹرفیس سے باہر جائے گا جس پر پیکٹ ابھی آیا ہے؟ جب جواب نہیں ہو، تو کرنل پیکٹ کو آتے ہی پھینک دیتا ہے۔ نہ کوئی ساکٹ اور نہ کوئی فارورڈنگ راستہ اسے کبھی دیکھتا ہے، اسی لیے سرنگ پر کی گئی گرفت اب بھی ایسی درخواست درج کرتی ہے جو ایپلیکیشن کو کبھی نہیں ملتی۔
یہاں کلائنٹ اپنی سرنگ پر 10.66.0.9 رکھتا ہے، اور OpenVPN سرور دفتر کے سابقے کے اندر 192.168.80.10 سے جواب دیتا ہے۔ 192.168.80.25 پر ایک ساتھی سرنگ کے پتے پر پنگ کرتا ہے، اس لیے درخواست LAN عبور کرتی ہے، سرور اسے سرنگ میں بھیجتا ہے، اور یہ دفتر کے ماخذ پتے کے ساتھ کلائنٹ کے سرنگ انٹرفیس پر پہنچتی ہے۔ اُس مشین کی روٹنگ جدول میں دفتر کا سابقہ ایتھرنیٹ ڈیوائس کا ہے، سرنگ کا نہیں۔ تصدیق آمد کے انٹرفیس کا راستے سے موازنہ کرتی ہے، عدم مطابقت پاتی ہے اور پیکٹ پھینک دیتی ہے، اس لیے ساتھی کو مکمل نقصان نظر آتا ہے جبکہ دونوں سرے صحت مند سرنگ کی اطلاع دیتے ہیں۔
آئینے کی سمت کی بھی وہی شکل ہے: جب کلائنٹ دفتر کی طرف شروع کرتا ہے، تو اسی وجہ سے دفتر کی طرف جوابات پھینکے جا سکتے ہیں۔ صرف ایک سمت میں جانچا گیا اصلاح عام طور پر دوسری ٹکٹ بن کر واپس آتا ہے۔
کسی بھی sysctl کو چھونے سے پہلے نافذ موڈ ثابت کریں
ڈسٹری بیوشن کے ڈیفالٹ پر بھروسا کرنے کے بجائے موثر اقدار پڑھیں، کیونکہ فی انٹرفیس ترتیب فیصلے کا صرف آدھا حصہ ہے۔ نافذ موڈ انٹرفیس قدر اور all قدر میں سے بلند تر ہے، اس لیے سرنگ انٹرفیس پر صفر کا کوئی مطلب نہیں جب تک all ایک ہو۔ سخت موڈ کا فیصلہ روٹنگ کا فیصلہ ہے، اس لیے وہی تلاش چلائیں جو کرنل چلاتا ہے اور اس کے جواب کا موازنہ اُس انٹرفیس سے کریں جس پر پیکٹ واقعی آیا۔
tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filterپھر غلطیوں کے شمارندے کو دیکھتے ہوئے پنگ دہرائیں۔ گرفت کے پہلے سے دکھائے گئے کسی درخواست کے ساتھ بڑھتا ہوا عدد اسی پھینکنے کا دستخط ہے، کسی گم شدہ راستے کا نہیں۔ وہاں رہتے ہوئے مریخ سیارے کے پیکٹوں کی لاگنگ چالو کریں، تاکہ کرنل اُس ماخذ اور انٹرفیس کا نام لے جسے اس نے رد کیا۔ مل کر وہ سائفر، فائر وال اور غائب iroute کو وضاحت کے طور پر خارج کر دیتے ہیں۔
کچھ بدلنے سے پہلے بنیادی لکیر لکھیں: دونوں قدریں، وہ ڈیوائس جو تلاش نے چنی، اور وہ شمارندہ جسے آپ دیکھ رہے تھے۔ تبدیلی نے وہی کیا جو آپ سوچتے ہیں یا نہیں، یہ بعد میں وہی ریکارڈ بتاتا ہے۔
ہر rp_filter موڈ واقعی کیا قبول کرتا ہے
کرنل فی انٹرفیس تین قدریں دکھاتا ہے، اور یہ ایک ہی قاعدے کے تین رنگ نہیں ہیں۔ صفر جانچ بند کر دیتا ہے۔ ایک سخت ہے اور چاہتا ہے کہ ماخذ آمد کے انٹرفیس سے واپس روٹ ہو۔ دو ڈھیلا ہے اور صرف یہ چاہتا ہے کہ جدول میں ماخذ تک کوئی راستہ موجود ہو، وہ جہاں بھی اشارہ کرے۔
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
یہاں اہم سطر ڈھیلی ہے، اور وہ جسے یہ اب بھی رد کرتی ہے۔ آپ کے جدول میں کہیں بھی روٹ ہونے کے قابل جعلی ماخذ گزر جاتا ہے، جبکہ بغیر کسی راستے والا ماخذ اب بھی مسترد ہوتا ہے۔ لیپ ٹاپ پر یہ تنگ رعایت ہے؛ دوسروں کی ٹریفک بھیجنے والے روٹر پر یہ کشادہ ہے۔ موڈ ہوسٹ کا ہے، اس لیے وہی عدد دو جگہوں پر مختلف وزن رکھتا ہے۔
اس ٹوپولوجی کو کون سی سطر درکار ہے، یہ عادت سے نہیں جدول سے نکلتا ہے۔ پیکٹ جائز ہے اور اس کا ماخذ روٹ ہونے کے قابل ہے، اس لیے ڈھیلا اسے قبول کرتا ہے اور سخت نہیں۔ اس معاملے میں کچھ بھی صفر کا تقاضا نہیں کرتا، اور صفر چننا ایسی جانچ ہٹا دے گا جس کی یہاں کوئی قیمت نہیں۔
ابہام دور کرنے والی سب سے چھوٹی تبدیلی چنیں
ڈھیلا موڈ سب سے چھوٹی موزوں تبدیلی ہے، اور یہ سختی میں حقیقی کمی ہے، کوئی بے ضرر سوئچ نہیں۔ جب بھی ٹوپولوجی اجازت دے بہتر اختیار موجود ہے: اوورلیپ ہٹائیں، اور ابہام غائب ہو جاتا ہے۔
جہاں دفتر کا سابقہ صرف ایتھرنیٹ کے ذریعے ضروری ہو، اسے پروفائل کے کھینچے راستوں سے ہٹا دیں، اور پتہ ایک ہی راستے سے قابل رسائی ہو جاتا ہے۔ جب دونوں راستوں کو واقعی ساتھ رہنا ہو، تو ہر انٹرفیس پر تصدیق ڈھیلی کرنے کے بجائے پالیسی قاعدے سے ماخذ اور ڈیوائس کو پن کریں۔ یہ مشین پر باقی سب کے لیے سخت فلٹرنگ رکھتا ہے اور استثنا وہاں درج کرتا ہے جہاں اگلا انجینئر اسے ڈھونڈے گا۔
آپ کوئی بھی راستہ چنیں، اسے زندہ کمانڈ میں نہیں بلکہ sysctl drop-in میں درج کریں۔ all اور default کلیدیں ساتھ مقرر کریں، تاکہ دوبارہ جڑنا سخت موڈ خاموشی سے بحال نہ کر سکے۔
# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --systemڈھیلا موڈ کیا چھوڑتا ہے، اور کہاں
ڈھیلا موڈ اب بھی ایسے ماخذ کو رد کرتا ہے جہاں کوئی راستہ نہ پہنچ سکے، اور اتفاقاً روٹ ہونے کے قابل جعلی ماخذ کو رد کرنا بند کر دیتا ہے۔ لیپ ٹاپ پر یہ تنگ رعایت ہے۔ جس ڈیوائس پر وہ ٹریفک بھیجی جاتی ہے جو اس کی اپنی نہیں، وہاں یہی انتخاب کہیں زیادہ کشادہ ہے۔ اس لیے وہی ترتیب اس بات پر منحصر دو بہت مختلف معنی رکھتی ہے کہ یہ کہاں چلتی ہے۔
دوسروں کے لیے ٹریفک بھیجنے والے ہوسٹ پر جانچ مکمل بند کرنا ہی وہ واحد مرمت ہے جس سے بچنا چاہیے۔ صفر وہ تصدیق پھینک دیتا ہے جسے ڈھیلا موڈ احتیاط سے رکھتا ہے۔ اگر ہوسٹ دوسروں کے لیے بھیجتا ہے، تو اس کے بجائے پچھلے حصے والے پالیسی قاعدے کے اختیار کی وکالت کریں۔
ایک نوٹ چھوڑیں جس میں دونوں انٹرفیس، اوورلیپ ہوتا سابقہ اور اب کامیاب ہونے والی درست جانچ کا نام ہو۔ فلٹرنگ ایڈجسٹ کی گئی کہنے والی سطر سے یہ اگلے انجینئر کے لیے زیادہ مفید ہے۔