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 सत्र से जोड़ना हो, तो देखे गए पता और समय-चिह्न को उसी अनुवाद मॉडल के अनुसार प्रामाणिक सत्र रिकॉर्ड से जोड़ें जिसे आपने प्रलेखित किया है। इससे ऐसा संबंध बनता है जिसका आप बचाव कर सकें; अकेला पता ऐसा नहीं करता।
निदान के लिए पूरे सर्वर ऐरे की जगह वही कुछ ज़रूरी फ़ील्ड लॉग करें, जो हेडर और प्रमाणीकरण सामग्री ले जा सकता है। उपयोगी निष्कर्ष बताता है कि इस परिनियोजन में इस मान का क्या अर्थ है, यह नहीं कि कौन-सा मान क्लाइंट जैसा सबसे ज़्यादा लगता है।