Docker میں OpenVPN /dev/net/tun نہیں کھول سکتا: کیا غائب ہے

کنٹینر امیجز اپنی ضرورت کی ہر OpenVPN بائنری اور کنفیگریشن فائل رکھ سکتی ہیں اور پھر بھی پہلی نیٹ ورک کال پر ناکام ہو سکتی ہیں۔ خرابی /dev/net/tun کا نام لیتی ہے کیونکہ ایپلیکیشن نے کرنل سے TUN انٹرفیس مانگا اور کنٹینر کے پاس نہ ڈیوائس نوڈ تھا اور نہ اسے بنانے کی صلاحیت۔ یہ دو الگ اجازتیں ہیں، اور ایک کو درست کرنے سے دوسری ٹھیک وہیں رہتی ہے جہاں تھی۔

انہیں الگ کرنے کے لیے ہر ایک کے لیے ایک کمانڈ درکار ہے۔ اس کے بعد کا خرابی پیغام آپ کو بتاتا ہے کہ آپ واقعی کس حد پر کھڑے تھے۔

ڈیوائس نوڈ اور صلاحیت دو دروازے ہیں

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

Docker کی devices سیٹنگ میزبان کے ڈیوائس کو کنٹینر میں نقش کرتی ہے، جبکہ cap_add صلاحیتوں کا سیٹ ایڈجسٹ کرتا ہے۔ اسی راستے کا bind mount فائل کو ڈیوائس رسائی کے معنی لاگو کیے بغیر نظر میں لاتا ہے۔

اسے Compose فائل سے باہر دوبارہ پیدا کریں

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

میزبان پر نوڈ نہ ہونے کا مطلب ہے کہ tun ماڈیول دستیاب نہیں، یہ کنٹینر کا نہیں بلکہ میزبان کی طرف کا ازالہ ہے۔ نوڈ موجود ہونے کے باوجود کنٹینر کے اندر نہ کھلنا ڈیوائس رسائی کی طرف اشارہ کرتا ہے، اور پیغام no such file کے بجائے permission denied کہے گا۔ ان دو ناکامیوں کی ترتیب ہی پوری تشخیص ہے۔ کوئی بھی جھنڈا بدلنے سے پہلے لکھیں کہ آپ نے کون سی دیکھی۔

TUN کے بعد کی خرابیاں مختلف مسائل ہیں

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

کام کرنے والی مثال سے ہر سیٹنگ کاپی کرنا ہی وہ راستہ ہے جس سے کم سے کم ازالہ ناقابلِ مطالعہ سروس تعریف بن جاتا ہے۔ صرف وہی لائیں جو اس تعیناتی کو درکار ہیں اور لکھیں کہ ہر ایک کیوں موجود ہے۔

کنٹینر کے اندر انٹرفیس کی تصدیق کریں

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

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set میں موجود مگر effective set میں غیر موجود صلاحیت کبھی نہ دی گئی صلاحیت سے مختلف برتاؤ کرتی ہے، اور capsh دونوں دکھاتا ہے۔ اگر نوڈ موجود ہو اور صلاحیت بھی ہو مگر بنانا پھر بھی ناکام ہو، تو رن ٹائم کچھ اور نافذ کر رہا ہے، جیسے seccomp پروفائل یا AppArmor پالیسی جو کارروائی کو محدود کرتی ہے۔ یہ تیسری حد ہے، جسے ایپلیکیشن نہیں بلکہ رن ٹائم دستاویز کرتا ہے۔

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