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 സെഷനുമായി ബന്ധിപ്പിക്കേണ്ടതുണ്ടെങ്കിൽ, നിരീക്ഷിച്ച വിലാസവും സമയ മുദ്രയും നിങ്ങൾ രേഖപ്പെടുത്തിയ വിവർത്തന മാതൃക അനുസരിച്ച് അധികാരമുള്ള സെഷൻ റെക്കോർഡുകളുമായി ബന്ധിപ്പിക്കുക. അത് നിങ്ങൾക്ക് പ്രതിരോധിക്കാവുന്ന ഒരു ബന്ധം ഉണ്ടാക്കുന്നു; വെറും വിലാസം അതു ചെയ്യുന്നില്ല.
രോഗനിർണയത്തിന് മുഴുവൻ സർവർ അറേയ്ക്കു പകരം ആവശ്യമായ ആ കുറച്ച് ഫീൽഡുകൾ ലോഗ് ചെയ്യുക, കാരണം അറേ ഹെഡറുകളും പ്രാമാണീകരണ സാമഗ്രികളും വഹിച്ചേക്കാം. ഉപയോഗപ്രദമായ നിഗമനം ഈ വിന്യാസത്തിൽ ഈ മൂല്യത്തിന്റെ അർത്ഥം എന്താണ് എന്ന് പറയുന്നു, ഏത് മൂല്യമാണ് ക്ലയന്റിനോട് ഏറ്റവും സാമ്യം എന്നല്ല.