സോക്കറ്റ് പിയർ vs ഫോർവേർഡഡ് ഹെഡർ: ഏത് വിലാസം വിശ്വസിക്കണം?

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

ശൃംഖല എഴുതിവയ്ക്കുക: ചുവടുകളുടെ ക്രമം, ഏത് ചുവട് ഫീൽഡ് സജ്ജീകരിക്കുന്നു, ഏത് ചുവട് വരുന്ന പകർപ്പുകൾ നീക്കുന്നു. തുടർന്ന് ആ കുറിപ്പ് ടിക്കറ്റിൽ മാത്രമല്ല, പ്രോക്സി കോൺഫിഗറേഷന് അരികിൽ സൂക്ഷിക്കുക. തുടർന്ന് അംഗീകരിച്ച പരിശോധനാ പ്രക്രിയിലൂടെ വ്യാജ ഹെഡറുള്ള അഭ്യർത്ഥന അയച്ച് ഉത്ഭവം അത് അവഗണിക്കുന്നുവെന്ന് സ്ഥിരീകരിച്ച് അത് പരീക്ഷിക്കുക.

ഒരു ചുവട് ചേർക്കുമ്പോൾ, ആ രേഖ വീണ്ടും പരിശോധിക്കുക. വിശ്വസ്ത പ്രോക്സിക്ക് മുൻപിൽ ചേർത്ത പുതിയ ലോഡ് ബാലൻസർ ആരും ആപ്ലിക്കേഷൻ തിരുത്താതെ ഏത് വിലാസം ജയിക്കുന്നു എന്നത് മാറ്റാം.

രണ്ട് നിരീക്ഷണങ്ങളും ലോഗിൽ സൂക്ഷിക്കുക

രോഗനിർണയം അനുവദനീയമായിടത്ത്, കണക്ഷന്റെ പിയറും സാധാരണവൽക്കരിച്ച ക്ലയന്റ് വിലാസവും രണ്ട് വേറിട്ട ഫീൽഡുകളായി രേഖപ്പെടുത്തുക, ലക്ഷ്യത്തിന് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഫോർവേർഡിംഗ് മെറ്റാഡാറ്റ മാത്രം ചേർക്കുക. തുടർന്ന് രണ്ട് അഭ്യർത്ഥനകളിലൂടെ വിന്യാസം തെളിയിക്കുക: രണ്ട് മൂല്യങ്ങളും ന്യായമായി രേഖപ്പെടുത്തേണ്ട പ്രോക്സി വഴിയുള്ളതും, നിരസിക്കപ്പെടേണ്ട ഉത്ഭവത്തിലേക്കുള്ള നേരിട്ടുള്ള ശ്രമവും.

ഈ ജോഡിയുടെ അർത്ഥം ഓർക്കുക. ഹെഡർ നിങ്ങൾ വിശ്വസിക്കാൻ തിരഞ്ഞെടുത്ത ഒരു ഘടകം നൽകുന്ന സന്ദർഭം ചേർക്കുന്നു; പിയർ നിങ്ങളുടെ ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ കണ്ട ഏക വിലാസമായി തുടരുന്നു. രണ്ടും വ്യക്തിഗത ഐഡന്റിറ്റിയുടെ തെളിവല്ല, ഏതെങ്കിലും ഒന്നിനെ തെളിവായി കണക്കാക്കുന്ന രൂപകൽപ്പന ആരെയെങ്കിലും കുറിച്ച് തെറ്റുപറയും.