HAProxy 302 نجی ایپ کی طرف: دوسری چھلانگ کون کھولتا ہے؟

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

دو راستے جو کنفیگریشن میں ایک جیسے لگتے ہیں

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

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

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

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

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

براؤزر کو کیا چاہیے جو سرور کا VPN نہیں دیتا

براؤزر کی اپنی درخواست کو چار چیزیں چاہیے جو اس کے پاس نہ ہوں: نجی نام کے لیے DNS جواب، اس پتے تک راستہ، سننے والی سروس تک پہنچنے کی اجازت، اور اس سروس کے پیش کردہ سرٹیفکیٹ پر اعتماد۔ پراکسی ہوسٹ کے پاس اپنی ٹنل کے ذریعے چاروں موجود ہیں۔ ان میں سے کوئی بھی ایسے کلائنٹ تک منتقل نہیں ہوتی جو کبھی اس ٹنل میں نہیں تھا، کیونکہ ٹنل URL کی نہیں، ہوسٹ کی خصوصیت ہے۔

یہی خلا «تقریباً کام کرتا ہے» کی علامت کی وضاحت کرتا ہے۔ پہلی درخواست کامیاب ہوتی ہے، ایڈریس بار بدلتا ہے، اور پھر کنکشن لٹک جاتا ہے یا ناکام ہو جاتا ہے جبکہ پراکسی پورے وقت صحت مند رہتی ہے۔ پراکسی کنفیگریشن میں کچھ بھی خراب نہیں، اور اسے ایڈجسٹ کرنا ایسے کلائنٹ کی مدد نہیں کر سکتا جس کے پاس 10.40.0.20 تک راستہ نہ ہو۔ یا تو کلائنٹ کو راستہ مل جائے، یا پراکسی کو اس کی طرف سے کنکشن بنانا پڑے۔

جب صرف پراکسی ہی ایپ تک پہنچ سکتی ہو

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

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

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

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

ایپ کے اپنے ری ڈائریکٹ اب بھی اندر کی طرف اشارہ کرتے ہیں

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

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

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

فیصلہ کریں کہ آپ کے پاس واقعی کون سا ڈیزائن ہے

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

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

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

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