VPN کنٹینر کے اندر ویب انٹرفیس تک پہنچنا: پورٹ کا مالک منتخب کریں

ایپ میں کوئی خرابی نہیں اور ٹنل میں بھی کوئی خرابی نہیں، پھر بھی ڈیش بورڈ لوڈ نہیں ہوتا۔ جب کوئی سروس network_mode: service:vpn کے ساتھ چلتی ہے تو وہ VPN کنٹینر کا نیٹ ورک نیم اسپیس شیئر کرتی ہے، یعنی اس کا سننے والا اور شائع شدہ پورٹس سروس کے نہیں بلکہ اسی نیم اسپیس کے ہیں۔ اسی سے تین فیصلے نکلتے ہیں: ایپ کہاں بندھتی ہے، کون سا کنٹینر پورٹ شائع کرتا ہے، اور انتظامی راستہ کتنا تنگ ہے۔ اگر یہ غلط ترتیب میں کریں تو ہر انفرادی سیٹنگ درست لگے گی، مگر مجموعہ کام نہیں کر سکے گا۔

پورٹ نیم اسپیس کا مالک کون ہے

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

میپنگ کے بائیں طرف کے پتے پر توجہ دیں۔ 127.0.0.1 پر باندھنے سے شائع شدہ پورٹ ہوسٹ کے لوپ بیک پر رہتا ہے، جو عام طور پر انتظامی انٹرفیس چاہتا ہے۔ 0.0.0.0 پر باندھنے سے وہ ہوسٹ کے ہر انٹرفیس پر کھل جاتا ہے، اور یہ سہولت نہیں بلکہ الگ سیکیورٹی فیصلہ ہے۔

ایپ کو وہاں سننے دیں جہاں نیم اسپیس کی توقع ہے

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

ایپ کے اندر سننے والوں کی فہرست بائنڈ پتے کے بارے میں سچ بتاتی ہے، اور docker port بتاتا ہے کہ مالک نے واقعی کیا شائع کیا۔ اگر پہلا 127.0.0.1 دکھائے اور دوسرا ہوسٹ میپنگ دکھائے، تو آپ نے VPN کنفیگریشن کو چھوئے بغیر عدم مطابقت پا لی۔

منتخب کریں کہ انتظامی راستہ کیسے داخل ہو

تین معقول ترتیبیں ہیں۔ VPN کنٹینر پر شائع کریں اور ہوسٹ یا مقامی نیٹ ورک سے وہاں پہنچیں۔ نیم اسپیس کے سامنے ایک معکوس پروکسی رکھیں اور پروکسی کو واحد کھلا پورٹ دیں۔ یا ڈیش بورڈ کو صرف نیم اسپیس کے اندر سے exec سیشن یا SSH ٹنل کے ذریعے قابل رسائی رکھیں، جو سب سے کم انکشاف اور سب سے کم سہولت ہے۔

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

سب کچھ کھولے بغیر انتظامی پورٹ کھولیں

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

ایپ کی اپنی توثیق فعال رکھیں۔ VPN سے منسلک اسٹیک کے اندر ہونا ہر مقامی صارف یا ہوسٹ تک پہنچنے والے ہر آلے کو اختیار نہیں دیتا، اور ٹنل کے پیچھے بغیر توثیق والا ایڈمن پینل بھی بغیر توثیق والا ایڈمن پینل ہی رہتا ہے۔

انتظامی ڈیوائس سے تصدیق کریں، پھر بعد میں دوبارہ تصدیق کریں

جس مشین واقعی سروس کا انتظام کرے گی اسی سے جانچیں، ہوسٹ سے نہیں، پھر ایپ کے مطلوبہ انٹرنیٹ راستے کی الگ تصدیق کریں۔ انتظام میں کامیابی ایک سمت ثابت کرتی ہے اور باہر جانے کے بارے میں کچھ نہیں کہتی۔

اسٹیک دوبارہ بننے کے بعد دوبارہ جانچیں۔ بدلا ہوا نیٹ ورک مالک اس نیم اسپیس کو بدل دیتا ہے جس سے ایپ منسلک ہوتی ہے، اور اپ ڈیٹ سے پہلے چلنے والا URL بعد میں کہیں اشارہ نہ کر سکے۔ شائع شدہ میپنگ اور بائنڈ پتہ لکھ لیں تاکہ اگلی تعمیر نو دوبارہ تحقیق نہ ہو بلکہ دو منٹ کی جانچ ہو۔