VPN کے پیچھے PHP کا REMOTE_ADDR دراصل کیا بتاتا ہے
یہ وہ قدر ہے جو آپ کے ویب سرور نے فراہم کی، ٹنل میں کوئی استفسار نہیں۔ درخواست کا راستہ دیکھیں، جائزہ لیں کہ کون اسے دوبارہ لکھ سکتا ہے، اور شناخت ایپلیکیشن میں رکھیں۔
کوئی پوچھتا ہے کہ VPN صارف ایپلیکیشن لاگ میں ایسے پتے کے ساتھ کیوں دکھائی دیتا ہے جو گیٹ وے کا ہے، یا ایسے پتے کے ساتھ جو دوپہر کے کھانے کے بعد بدل گیا۔ جواب اس سے شروع ہوتا ہے کہ یہ قدر کیا ہے: ایسی اندراج جو ویب سرور نے درخواست کے ماحول میں رکھی۔ یہ ٹنل میں استفسار نہیں، سرٹیفکیٹ کی شناخت نہیں، اور یہ وعدہ نہیں کہ نمبر کسی ایک شخص کا ہے۔ اسے ان تینوں میں سے کچھ بھی سمجھ کر پڑھنا ایسے پُراعتماد جواب دیتا ہے جو مختلف طریقوں سے غلط ہیں۔
قدر سرور سے آتی ہے، ٹنل سے نہیں
PHP درخواست کا ماحول اُس چیز سے حاصل کرتا ہے جس نے اسکرپٹ چلایا۔ PHP کے سرور متغیرات کا حوالہ ان اندراجات کو ویب سرور کا بنایا ہوا بتاتا ہے، اور اُن کی دستیابی اس پر منحصر ہے کہ درخواست کیسے پہنچی۔
VPN کے کمانڈ لائن ہک کے طور پر چلنے والا اسکرپٹ بالکل مختلف عمل آوری کا سیاق ہے۔ اس کے پاس نہ ویب درخواست ہے، نہ کلائنٹ ساکٹ، نہ REMOTE_ADDR، اسی لیے ہک میں نقل کیا گیا ویب کوڈ غلط قدروں کی بجائے خالی قدریں دیتا ہے۔ ہک کا اپنا ماحول ہے جسے ڈیمن بھرتا ہے، اور وہ الگ سے دستاویز شدہ ہے۔ وہاں REMOTE_ADDR تک پہنچنا ایسے متغیر تک پہنچنا ہے جو کبھی مقرر نہیں ہوا۔
دو لاگ موازنہ کرنے سے پہلے یہ فرق ذہن میں رکھیں۔ ممکن ہے آپ صفحے کی درخواست کا موازنہ کسی ہک سے کر رہے ہوں، اور یہ کوئی موازنہ ہی نہیں۔ پہلے عمل آوری کا سیاق دیکھیں اور بعد میں پتہ۔
نمبر پر اعتماد سے پہلے درخواست کا راستہ دیکھیں
بتایا گیا پتہ اُس رابطے کا ہم منصب ہے جو ویب سرور نے دیکھا۔ کلائنٹ اور اُس سرور کے درمیان کچھ بھی رکھیں اور ہم منصب بدل جاتا ہے۔ ترجمہ، اختتام اور بوجھ کی تقسیم ہر ایک مشاہدے کو صارف سے ایک قدم مزید دور لے جاتی ہے۔
چار عام راستے چار مختلف مشاہدے دیتے ہیں۔
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
راستہ منزل کے نام، پتوں کے خاندان اور ہر ترجمے کے مقام کے ساتھ لکھیں۔ اس نقشے کے بغیر درست اور غلط قدر لاگ کی ایک سطر میں یکساں نظر آتی ہیں۔ خاکے کی دو سطریں دوپہر بھر کی بحث بچاتی ہیں۔
تبدیلی صرف وہیں ہوتی ہے جہاں وہ ترتیب دی گئی ہو
سرور یا فریم ورک کلائنٹ کا پتہ جان بوجھ کر بدل سکتا ہے۔ Apache کا remote-IP ماڈیول اور NGINX کا real-IP ماڈیول دونوں یہ کرتے ہیں، اور PHP کو ملنے والی قدر اسی ترتیب اور اسکرپٹ ہینڈلر کو دیے گئے پیرامیٹرز پر منحصر ہے۔
یعنی REMOTE_ADDR ہمیشہ اچھوتا TCP ہم منصب نہیں ہوتا۔ یہ وہ ہم منصب ہے جیسے سرور نے اپنی پالیسی لاگو کرنے کے بعد بتانا چنا۔ یہی فرق طے کرتا ہے کہ قدر ثبوت ہے یا آرائش۔
سرور کے مالک سے پوچھیں کہ اس تعیناتی میں کون سا میدان مستند ہے اور تبدیلی کے وقت اصل ہم منصب کیسے محفوظ رہتا ہے۔ اگر کوئی جواب نہ دے سکے تو لاگ ابھی کچھ ثابت نہیں کرتا۔
فارورڈنگ ہیڈر بھروسے سے نہ پڑھیں
کال کرنے والا خود بھی فارورڈنگ ہیڈر بھیج سکتا ہے۔ کوما سے جُدا پہلی اندراج کو تصدیق شدہ صارف کا پتہ سمجھنا یہ فیصلہ ہے کہ ہر جڑنے والے پر یقین کیا جائے، جو ہیڈر کے مقصد کے بالکل برعکس ہے۔ ہیڈر ایک زنجیر بیان کرتا ہے، اور صرف قابلِ اعتماد تہہ ہی اُس زنجیر کی ضمانت دے سکتی ہے۔
سرور یا فریم ورک کی قابلِ اعتماد پراکسی معاونت اصل پراکسی زنجیر کے ساتھ ترتیب دے کر استعمال کریں، اور اسے اجازت دیں کہ اُس زنجیر سے باہر کے ذرائع کی قدریں رد کر دے۔ ہاتھ سے لکھی گئی تجزیہ گری وہ جگہ ہے جہاں زیادہ تر دلچسپ خرابیاں رہتی ہیں۔
پراکسی کا بتایا ہوا پتہ بھی اُس پیکٹ کے منبع کو نہیں بدلتا جو اوپر کا فائر وال دیکھتا ہے۔ HTTP میٹا ڈیٹا اور نیٹ ورک فلٹرنگ کو الگ مشاہدے رکھیں، کیونکہ وہ مختلف سوالوں کے جواب دیتے ہیں۔
فیصلوں کے لیے ایپلیکیشن کی شناخت استعمال کریں
صارف کے ریکارڈ تک رسائی کے لیے تصدیق شدہ فریق اور ایپلیکیشن کے اجازت کے قواعد پر بھروسہ کریں۔ اندرونی پتہ دوبارہ مختص ہو سکتا ہے، اور ایک مترجم پتہ سینکڑوں بیک وقت صارفین کی نمائندگی کر سکتا ہے۔ اِن خصوصیات میں سے کوئی بھی پتے کی جانچ ٹھیک نہیں کر سکتی۔
اگر آپریشنز کو کسی درخواست کو VPN سیشن سے جوڑنا ہو تو مشاہدہ شدہ پتہ اور وقت کی مہر کو اُس ترجمہ ماڈل کے مطابق مستند سیشن ریکارڈ سے جوڑیں جو آپ نے دستاویز کیا۔ اس سے ایسا تعلق بنتا ہے جس کا آپ دفاع کر سکیں؛ صرف پتہ ایسا نہیں کرتا۔
تشخیص کے لیے صرف وہ چند میدان لاگ کریں جو آپ کو درکار ہیں، پورے سرور ارے کی بجائے، جو ہیڈر اور تصدیقی مواد ساتھ رکھ سکتا ہے۔ مفید نتیجہ یہ بتاتا ہے کہ اس تعیناتی میں اس قدر کا مطلب کیا ہے، نہ یہ کہ کون سی قدر کلائنٹ سے زیادہ مشابہ ہے۔