Nginx سامنے، VPN کے پیچھے نجی بیک اینڈ

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

ایک درخواست کو دو کنکشنز سے گزرتے ہوئے دیکھنا

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

باہر جانے والا حصہ نجی ہے۔ Nginx کلائنٹ بن جاتا ہے، کوئی اندرونی نام حل کرتا ہے یا مقررہ پتہ استعمال کرتا ہے، اور ایسی سروس تک پہنچتا ہے جو انٹرنیٹ سے آنے والا کنکشن مسترد کر دیتی۔

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

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

اس میں سے کچھ بھی بنانے سے پہلے تصدیق کریں کہ ایپلیکیشن کی اشاعت ارادی ہے۔ کام کرنے والا پراکسی بھی کام کرنے والا انکشاف ہے، اور تصدیق کا ماڈل فیصلہ ہونا چاہیے، ضمنی اثر نہیں۔

گیٹ وے کا نام سرنگ سے بچ کر نکلنا چاہیے

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

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

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

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

سرور بلاک اس طرح لکھیں کہ دونوں حصے تصدیق کریں

فرض کریں کہ بیک اینڈ اس نام کے لیے سرٹیفکیٹ پیش کرتا ہے: backend.corp.example اور نجی پتے پر جواب دیتا ہے۔ کسی نام کی تصدیق کرتے ہوئے کسی پتے سے جڑنا بالکل وہی کام ہے جس کے لیے پراکسی ماڈیول کے SNI اور نام کے اختیارات ہیں۔

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/tls/app-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/app-key.pem;

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

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

proxy_set_header Host app.example.com جان بوجھ کر ہے۔ بیک اینڈ کو اس طرح ترتیب دینا چاہیے کہ وہ اس عوامی اصل کو قبول کرے، اور اسے فارورڈ شدہ ہیڈرز پر صرف اسی فرنٹ اینڈ سے اعتماد کرنا چاہیے۔ اوپر لکھنا X-Forwarded-For کلائنٹ کے پتے سے ایک پراکسی کے لیے درست ہے اور زنجیر کے لیے غلط، اس لیے کثیر پراکسی تعیناتی کو قابل اعتماد پتوں کا اپنا انتظام درکار ہے۔

عوامی اصل سے ویسا ہی برتاؤ کرانا

ایپلیکیشن کو عوامی اصل کے لیے مطلق URLs، ری ڈائریکٹس اور کوکیز جاری کرنی چاہئیں۔ اگر یہ کسی مہمان کو اس طرف بھیجے: backend.corp.example، تو وہ مہمان ایسے نام پر بھیجا جاتا ہے جو وہ حل نہیں کر سکتا۔

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

کوکیز بھی اسی توجہ کی مستحق ہیں۔ نجی نام تک محدود کوکی ایسا براؤزر کبھی نہیں بھیجے گا جو صرف عوامی نام جانتا ہو۔

یہ بھی تصدیق کریں کہ Nginx واقعی عوامی ساکٹ کا مالک ہو سکتا ہے۔ 443 پر موجود ویب سروس کو ہٹنا ہوگا یا فرنٹ اینڈ کو کہیں اور رہنا ہوگا، کیونکہ دو عمل ایک ہی پتہ اور پورٹ نہیں باندھ سکتے۔

ہر حصے کو وہیں جانچیں جہاں وہ واقعی چلتا ہے

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

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

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

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