OpenVPN کا "File exists" کسی راستے پر فائل کا مسئلہ نہیں

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

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

کلائنٹ واقعی کیا مانگ رہا تھا

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

موجودہ راستہ پڑھیں، صرف پتہ نہیں

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

سابقے کے چار مالک ہو سکتے ہیں

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

ہر مالک کو مختلف اصلاح درکار ہے۔ منسلک راستہ آپ کا مٹانے کے لیے نہیں؛ اسے ہٹانا ٹنل کے قابل استعمال ہونے سے پہلے مقامی رسائی توڑ سکتا ہے، اور کرنل اسے واپس رکھ دے گا۔ مینیجر کی ملکیت والا راستہ اسی مینیجر کے ذریعے بدلنا چاہیے، نہ کہ ہاتھ سے لکھے ip route del سے جسے اگلا دوبارہ جڑنا منسوخ کر دیتا ہے۔

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

block-local ایک مختلف سوال کا جواب دیتا ہے

جب پروفائل ساری ٹریفک ٹنل سے بھیجتی ہے، تو کلائنٹ کو طے کرنا ہوتا ہے کہ مقامی نیٹ ورک کا کیا ہوگا۔ block-local پرچم مقامی LAN کو ٹنل سے گزاردے ہوئے وہ فیصلہ بدلتا ہے، ساتھ ہی LAN گیٹ وے کے لیے دستاویزی استثنا برقرار رکھتا ہے؛ یہ ٹریفک پالیسی کا انتخاب ہے جس کے رسائی پر نمایاں نتائج ہیں۔

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

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

چکر بند کریں: دہرائی اس کے ماخذ پر ہٹائیں

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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