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

അനുവദനീയമായ ബാഹ്യ അഭ്യർത്ഥന ഫ്രണ്ട്-എൻഡ്, ബാക്കെൻഡ് എന്നിവയുടെ രണ്ട് രേഖകളുമായും താരതമ്യം ചെയ്ത്, നിരസിക്കേണ്ട നിയമം ഇപ്പോഴും നിരസിക്കുന്നുവെന്നും അനുവദിക്കേണ്ട നിയമം ഇപ്പോഴും അനുവദിക്കുന്നുവെന്നും ഉറപ്പാക്കുക. ലോഗ് വരി ശരിയാണെങ്കിലും നിയമം ഇപ്പോഴും എല്ലാവരെയും പ്രാദേശികരായി കണക്കാക്കുന്നുവെങ്കിൽ, നിയമം നിങ്ങൾ തിരുത്തിയ ഫീൽഡിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ഫീൽഡ് വായിക്കുന്നു.

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