/dev/net/tun موجود نہیں جبکہ tun لوڈ ہے: ڈیوائس نوڈ ٹھیک کریں

OpenVPN errno 2 شکایت کے ساتھ رک جاتا ہے، وہ /dev/net/tun کے بارے میں ہے، جبکہ lsmod tun ماڈیول کو آرام سے فہرست کرتا ہے۔ دونوں حقائق ایک ہی وقت میں سچ ہیں۔ ماڈیول ڈرائیور دیتا ہے، اور کلائنٹ جو راستہ کھولتا ہے وہ ڈیوائس نوڈ ہے جسے کوئی اور بنانا ہوتا ہے۔ دونوں کو ایک ہی شے سمجھنا ہی وہ وجہ ہے کہ ماڈیول دوبارہ لوڈ کرنے کا واضح حل کچھ بھی نہیں بدلتا۔

دو اشیاء، دو مختلف مالک

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

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

lsmod | grep -w tun
stat -c "%F %t:%T" /dev/net/tun
grep " /dev " /proc/mounts

devtmpfs بمقابلہ واضح mknod

عام طور پر دو میکانزم وہ نوڈ بناتے ہیں، اور یہ جاننا کہ کس کو ذمہ دار ہونا چاہیے بتاتا ہے کہ کیا ٹھیک کرنا ہے۔ devtmpfs کرنل کو ماونٹ شدہ انسٹانس میں ڈیوائس نوڈ بنانے دیتا ہے، اور udev ان پر ملکیت اور اجازتیں لاگو کرتا ہے۔ ایک واضح mknod ان امیجز اور نام کی جگہوں کے لیے ہاتھ کا راستہ ہے جہاں بوٹ پر دونوں میں سے کوئی نہیں چلتا۔

ارادوں کی نہیں، نتائج کی موازنہ کریں۔ اگر devtmpfs /dev پر ماونٹ ہے اور نوڈ اب بھی موجود نہیں، تو ڈرائیور وہ نہیں جو آپ سمجھ رہے ہیں، یا کسی نے بوٹ کے بعد نوڈ ہٹا دیا۔ اگر /dev کھلی rootfs کے اندر ایک عام ڈائریکٹری ہے، تو کوئی خودکار میکانزم نہیں اور امیج بنانے والے کو نوڈ بنانا ہوگا۔

stat -c "%F major=%t minor=%T" /dev/net/tun
# expect: character special file major=a minor=c8

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

sudo modprobe tun
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun
ls -l /dev/net/tun

سب سے تیز امتیاز stat کی بتائی قسم ہے، اور اس راستے پر ڈائریکٹری کا ہونا کم سے کم امیجز میں سب سے عام حیرت ہے۔ نیک نیتی سے لکھا mkdir Dockerfile میں بالکل وہی چھوڑ دیتا ہے، اور کتنے ہی ماڈیول لوڈ کیے جائیں، ڈائریکٹری کو حرفی ڈیوائس سے نہیں بدلا جا سکتا۔ Major 10 اور minor 200 tun کے لیے رجسٹر شدہ جوڑی ہے، جو ہیکس میں a اور c8 کے طور پر بیان کی جاتی ہے۔

چار نشان، چار وجوہات

چار وجوہات تقریباً ہر معاملے کی وضاحت کرتی ہیں، اور ہر ایک لاگ میں مختلف نشان چھوڑتی ہے۔ بوٹ ماحول سے شروع کریں۔ ڈسک کے بغیر امیجز، ایمبیڈڈ بورڈز اور initramfs مراحل اکثر نہ devtmpfs اور نہ udev کے زیرِ انتظام /devماونٹ کرتے ہیں، اس لیے کوئی عمل کبھی نوڈ نہیں لکھتا۔ پھر /devکی میزبانی کرنے والے کے ماونٹ آپشنز پڑھیں، کیونکہ nodev راستے کو موجود رہنے دیتا ہے مگر اسے کھولنے سے انکار کرتا ہے، اور سخت کیے گئے میزبان سے لی گئی bind ماونٹ یہ جھنڈا خود اعلان کیے بغیر اٹھاتی ہے۔ صرف پڑھنے والی ماونٹ پہلے اور بلند آواز میں ناکام ہوتی ہے: mknod وہاں EROFS واپس کرتا ہے، جبکہ EPERM کا مطلب ہے کہ عمل میں صلاحیت نہیں، یہ نہیں کہ فائل سسٹم خود کو بچا رہا ہے۔ آخر میں، اپنے /dev tmpfs والے کنٹینر رن ٹائم کو نوڈ اپنی نام کی جگہ میں داخل کرنا پڑتا ہے، اور اس کے ڈیوائس cgroup کو major اور minor جوڑی کی اجازت دینی ہوتی ہے۔

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

sudo journalctl -k -n 20 --no-pager
sudo ausearch -m AVC -ts recent | tail -5

اسے انٹرفیس سے ثابت کریں، فہرست سے نہیں

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

head -c 1 /dev/net/tun
head: error reading '/dev/net/tun': File descriptor in bad state

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

sudo ip tuntap add dev tun7 mode tun
ip -brief link show tun7
sudo ip tuntap del dev tun7 mode tun

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

جب ڈیوائس مسئلہ نہ ہو

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

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