ساکٹ ہم منصب یا بھیجا گیا ہیڈر: کس پتے پر اعتماد کریں؟

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

کسی بھی چیز کا موازنہ کرنے سے پہلے راستہ بیان کریں:

Client -> approved reverse proxy -> application origin

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

پتے کی دو قسم کی شہادتیں

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

فارورڈنگ فیلڈ زنجیر کے بارے میں میٹا ڈیٹا ہے۔ X-Forwarded-For، X-Real-IP اور معیاری فیلڈ Forwarded ہر وہ کلائنٹ لکھ سکتا ہے جو ایسے اینڈ پوائنٹ تک پہنچے جو انہیں واپس دہراتا ہے، اس لیے ان کی اعتبار کا انحصار مکمل طور پر اس بات پر ہے کہ انہیں مقرر کرنے کی اجازت کس کو تھی۔

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

ہیڈر کبھی کنکشن کا راستہ نہیں بدلتا

فارورڈنگ فیلڈ میں پتہ لکھنا سرور تک پہنچنے والے TCP کنکشن کے ماخذ کو نہیں بدلتا، اور راستے میں کہیں بھی روٹنگ نہیں بدلتا۔ عام VPN روٹنگ یا ماخذ NAT بغیر کسی HTTP ہیڈر کے ٹریفک پہنچاتا ہے۔ اسی طرح، ٹرانزٹ گیٹ وے TLS اینڈ پوائنٹ کی ترتیب بدلے بغیر درست طور پر محفوظ HTTPS تبادلے کو دوبارہ نہیں لکھتا۔

الٹی غلطی بھی اتنی ہی عام ہے: HTTPS کلائنٹ کی فراہم کردہ فارورڈنگ ہیڈر کو سچ نہیں بناتا۔ یہ جھوٹے دعوے کی ترسیل کو سچے دعوے کی طرح ہی محفوظ رکھتا ہے۔

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

اس پراکسی کا نام لیں جسے دعویٰ کرنے کی اجازت ہے

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

NGINX کا اصل IP ماڈیول تقسیم واضح طور پر دکھاتا ہے۔ set_real_ip_from ان بھیجنے والوں کے نام لیتا ہے جن کا دعویٰ شمار ہوتا ہے، اور real_ip_header بتاتا ہے کہ کون سی فیلڈ اسے لے جاتی ہے؛ پہلا اعتماد کرتا ہے، دوسرا صرف یہ بتاتا ہے کہ کہاں دیکھنا ہے۔

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

محض ہیڈر کے انتخاب کی ہدایت بذات خود ابھی تک اس بارے میں کچھ ثابت نہیں کرتی کہ قدر کس نے بھیجی۔

ٹرانسپورٹ سلامتی کو آپ کے قابلِ اعتماد اجزاء کے درمیان پورا راستہ طے کرنا ہوتا ہے۔ درست طور پر معمول پر لانے والا کنارہ وہ قدر اسی لمحے کھو دیتا ہے جب نیچے کا غیر محفوظ مرحلہ سفر کے دوران کسی اور کو دعویٰ میں ترمیم کرنے دیتا ہے۔

کئی مرحلوں والی زنجیروں کو سوچ سمجھ کر سنبھالیں

کئی پراکسیوں کو واضح زنجیر ماڈل درکار ہوتا ہے۔ محض اس لیے کہ کسی بلاگ پوسٹ نے ایسا کیا، کوما سے الگ کی گئی سب سے بائیں یا دائیں قدر نہ لیں؛ معلوم کریں کہ آپ کی کون سی پراکسی اضافہ کرتی ہے، کون سی متبادل کرتی ہے اور کون سی آنے والی فیلڈ محفوظ رکھتی ہے۔ مثال کے طور پر، NGINX اپنے قابلِ اعتماد مجموعے کے مقابلے میں فہرست کو پیچھے کی طرف چل سکتا ہے اور پہلے ایسے پتے پر رک سکتا ہے جو اس کی ملکیت نہ ہو، اور یہ اسی مصنوع کا قاعدہ ہے، کوئی ایسا قانون نہیں جس کی ہر فریم ورک پیروی کرے۔ اپنی پراکسی کی دستاویزات انہی دو سوالوں کے ساتھ پڑھیں: یہ کون سی قدر منتخب کرتی ہے، اور کن بھیجنے والوں پر یقین کرتی ہے؟

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

جب آپ کوئی مرحلہ شامل کریں تو وہ دستاویز دوبارہ دیکھیں۔ قابلِ اعتماد پراکسی کے سامنے ڈالا گیا نیا لوڈ بیلنسر بغیر کسی کے ایپلیکیشن میں ترمیم کیے یہ بدل سکتا ہے کہ کون سا پتہ جیتتا ہے۔

دونوں مشاہدے لاگ میں رکھیں

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

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