Port-Share کیوں ہر ویب سائٹ وزٹر کو localhost جیسا دکھاتا ہے

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

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

لاگ لائن نہیں، دونوں کنکشن کی پیروی کریں

Port-Share ایک TCP سننے والے پر دو پروٹوکول ملٹی پلیکس کرتا ہے۔ OpenVPN آنے والے کنکشن کے پہلے بائٹ دیکھتا ہے، جب وہ اپنے پروٹوکول جیسا لگے تو اسے رکھ لیتا ہے، اور باقی سب کچھ دوسری منزل کو دے دیتا ہے۔ وہ منزل عام طور پر اسی ہوسٹ کا ویب سرور ہوتی ہے، اس لیے ویب سرور کے قبول کردہ ساکٹ کا ساتھی OpenVPN عمل ہوتا ہے۔

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

ٹرانسپورٹ فارورڈنگ ہیڈر انجیکشن نہیں ہے

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

اصل پتہ دو طریقے لے جا سکتے ہیں، اور دونوں کو دونوں سروں پر اتفاق چاہیے۔ PROXY پروٹوکول کنکشن کے آغاز میں چھوٹا ہیڈر جوڑتا ہے، اور بیک اینڈ کو اس کی توقع کے لیے ترتیب دیا جانا چاہیے؛ جو بیک اینڈ اس کی توقع نہیں کرتا وہ ان بائٹ کو درخواست کا آغاز سمجھ کر الجھن بھرے انداز میں ناکام ہوگا۔ X-Forwarded-For جیسے قابل اعتماد پراکسی ہیڈر اس وقت کام کرتے ہیں جب HTTP سمجھنے والا پراکسی انہیں مقرر کرے اور بیک اینڈ کو بتایا جائے کہ کن ساتھیوں کو ان کا دعویٰ کرنے کی اجازت ہے۔

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

اختیاری ماخذ میپنگ ڈائریکٹری

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

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

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

فیصلہ کریں کہ کون سا جزو پتے کی ضمانت دیتا ہے

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

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

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

قاعدے کی جانچ کریں، صفحے کی نہیں

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

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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