OpenVPN میں پہلے سے بنایا گیا tun: دو ملکیت ماڈلز کا موازنہ

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

نام جڑنا نہیں ہے

dev tun1 OpenVPN سے وہی نام والا انٹرفیس مانگتا ہے، اور روایتی صارف کی جگہ کی تعمیرات اسے کھولنے کی کوشش کریں گی۔ اگر نام عام tun یا tap نمونے کی پیروی نہیں کرتا تو پروفائل کو متعلقہ dev-type بھی درکار ہے، کیونکہ قسم کبھی کسی سٹرنگ سے اخذ نہیں کی جاتی۔ TAP آلہ کسی دوسرے لیبل والا TUN آلہ نہیں ہے: غلط کو جوڑنا یا تو فوراً ناکام ہو جاتا ہے، یا ایسا رابطہ بناتا ہے جو وہ فریم اٹھاتا ہے جن کی کوئی توقع نہیں کرتا۔ سب سے پہلے قسم جانچیں، کیونکہ ہر بعد کی جانچ یہ مانتی ہے کہ دونوں فریق اس پر متفق ہیں۔ اس کے بعد تصدیق کریں کہ عمل واقعی آلہ کھول سکتا ہے، صرف دیکھ سکتا ہے یہ نہیں۔

dev tun1
dev-type tun

نیٹ ورک انٹرفیس اور /dev/net/tun الگ چیزیں ہیں: ایک نام کی جگہ کے اندر رابطہ ہے، دوسرا وہ حرفی آلہ ہے جو صارف کی جگہ کا پروگرام جڑنے کے لیے استعمال کرتا ہے۔ Linux TUN/TAP دستاویز اس جڑنے کے راستے اور مستقل آلات کی ملکیت کے قواعد بیان کرتی ہے۔ ip link چلا سکنے والا root شیل صرف یہ ثابت کرتا ہے کہ شیل کو اختیارات ہیں، ڈیمن کو ہیں یہ نہیں۔ آلے کے نوڈ کی ملکیت، سروس کی صلاحیتوں کا مجموعہ اور جس صارف کے تحت یہ چلتا ہے — سب کو میل کھانا چاہیے، کھلنے کی کامیابی سے پہلے۔

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

رابطہ کون ترتیب دیتا ہے: دو ملکیت ماڈلز

پہلے ماڈل میں OpenVPN رابطہ اٹھانے کے حصے کے طور پر پتے اور راستے ترتیب دیتا ہے۔ یہی طے شدہ رویہ ہے اور سمجھنے میں سب سے آسان، کیونکہ ایک ہی جزو حالت بناتا ہے اور پھر اسے ہٹا دیتا ہے۔ دوسرے ماڈل میں بیرونی منتظم انٹرفیس کا مالک ہوتا ہے، اور ifconfig-noexec OpenVPN کو اس کے پتوں کی ترتیب کے احکام چلانے سے روکتا ہے اور پیرامیٹرز اسکرپٹس کو دیتا ہے۔ پھر منتظم کو خود صحیح مقامی اور ساتھی ترتیب لاگو کرنی پڑتی ہے، جو اختیار کے نام سے ظاہر ہونے والی محنت سے زیادہ ہے۔ دونوں میں انتخاب اس سوال کا جواب ہے کہ رابطہ اوپر ہونے کے دوران اسے کون بدل سکتا ہے۔

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

آلے کو اسی نام کی جگہ سے دیکھیں جو اہم ہے

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

ip -details link show dev tun1
ip tuntap show

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

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

دو قسم کی پائیداری

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

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

صرف آغاز جانچنے پر کیا ٹوٹتا ہے

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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