proxy_redirect NGINX-നെ നിങ്ങളുടെ VPN ഹോസ്റ്റുമായി ബന്ധിപ്പിക്കുന്നില്ല
proxy_redirect ഇതിനകം എത്തിയ പ്രതികരണത്തിലെ തലക്കെട്ടുകൾ പുനരെഴുതുന്നു; അത് ഒരിക്കലും upstream തിരഞ്ഞെടുക്കുന്നില്ല. proxy_pass, ബാക്കെൻഡിലേക്കുള്ള റൂട്ട്, പിന്നെ തലക്കെട്ടുകൾ എന്നിവ പരിശോധിക്കുക.
പേരിൽ redirect എന്ന വാക്കുണ്ട്, അതിനാൽ VPN-ന് പിന്നിലുള്ള ബാക്കെൻഡ് ലഭ്യമല്ലാത്തപ്പോൾ അത് location ബ്ലോക്കിൽ ഒട്ടിക്കുന്നു. ഒന്നും മാറുന്നില്ല, വ്യക്തമായ നിഗമനം ഈ നിർദ്ദേശം തകർന്നിരിക്കുന്നു എന്നോ മറ്റൊരു വാക്യഘടന വേണം എന്നോ ആണ്. യഥാർത്ഥത്തിൽ സംഭവിച്ചത് കൂടുതൽ ലളിതവും പ്രശംസയർഹിക്കാത്തതുമാണ്: proxy_redirect ഇതിനകം തിരികെ വന്ന ഒരു പ്രതികരണത്തിൽ പ്രവർത്തിക്കുന്നു, ഈ വിന്യാസത്തിൽ ഒരു അഭ്യർത്ഥനയും അത്രയും ദൂരം എത്തിയിരുന്നില്ല.
ഒരു അഭ്യർത്ഥനയിൽ രണ്ട് നിർദ്ദേശങ്ങൾ, രണ്ട് നിമിഷങ്ങൾ
റിവേഴ്സ് പ്രോക്സിയിലൂടെ കടന്നുപോകുന്ന ഒരു HTTP അഭ്യർത്ഥന ക്രമത്തിൽ നിരവധി തീരുമാനങ്ങളിലൂടെ കടന്നുപോകുന്നു, രണ്ട് നിർദ്ദേശങ്ങളും ആ ക്രമത്തിന്റെ എതിർ അറ്റങ്ങളിലാണ്. ഒന്ന് അഭ്യർത്ഥന എവിടേക്ക് പോകണമെന്ന് തിരഞ്ഞെടുക്കുന്നു. മറ്റൊന്ന് തിരികെ വരുന്ന പ്രതികരണത്തിലെ ചില തലക്കെട്ടുകൾ തിരുത്തുന്നു.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
ആ ക്രമമാണ് മുഴുവൻ ഉത്തരം. ആദ്യ വരി പരാജയപ്പെട്ടതിനാൽ രണ്ടാം വരി ഒരിക്കലും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, രണ്ടാം നിർദ്ദേശം തെറ്റായി ക്രമീകരിച്ചതല്ല, അത് വെറും എത്തിച്ചേരാനാകാത്തതാണ്. രണ്ടാം വരി എത്ര വീണ്ടും എഴുതിയാലും അത് തിരുത്തേണ്ടിയിരുന്ന പ്രതികരണം ഉണ്ടാകില്ല. ആദ്യ വരിയിൽ നിന്ന് പുറത്തേക്ക് രോഗനിർണയം നടത്തുക, ആശയക്കുഴപ്പമുള്ള പെരുമാറ്റം നഷ്ടപ്പെട്ട റൂട്ടിലോ നിരസിക്കപ്പെട്ട കണക്ഷനിലോ എത്തിച്ചേരുന്നു.
upstream തിരഞ്ഞെടുക്കൽ proxy_pass-ന്റെ ജോലിയാണ്
NGINX ഒരു പൊതു പ്രവേശന ഹോസ്റ്റിൽ പ്രവർത്തിക്കുകയും അതിന്റെ VPN വഴി 10.40.0.20:8080-ലെ ഒരു ആപ്ലിക്കേഷനിൽ എത്തുകയും ചെയ്യുന്നു എന്ന് കരുതുക. ആ ആപ്ലിക്കേഷൻ തിരഞ്ഞെടുക്കുന്ന ഭാഗം നിലവിലുള്ള ഒരു server ബ്ലോക്കിനുള്ളിൽ ഇങ്ങനെ കാണാം:
location / {
proxy_pass http://10.40.0.20:8080;
}യഥാർത്ഥ സ്കീം, വിലാസം, പോർട്ട് എന്നിവ ഉപയോഗിക്കുക, ഇതിനെ ഒരു വിന്യാസമായല്ല ഭാഗമായി കാണുക. പ്രവേശന ഹോസ്റ്റ് VPN റൂട്ട്, അനുവദനീയമായ ഫോർവേഡിംഗ് പാത, ആ സേവനത്തിലേക്കുള്ള പ്രവർത്തിക്കുന്ന മടക്ക ട്രാഫിക് എന്നിവയും സൂക്ഷിക്കണം, കാരണം കടലാസിൽ ഒരു വിലാസത്തിൽ എത്തുന്ന പ്രോക്സിക്കും കെർണലിന്റെ സമ്മതം ആവശ്യമാണ്.
proxy മൊഡ്യൂളിന്റെ റഫറൻസ് upstream തിരഞ്ഞെടുക്കലിനെ പ്രതികരണ തലക്കെട്ടുകളുടെ പുനരെഴുത്തിൽ നിന്ന് വേർതിരിച്ചു നിർത്തുന്നു, കൂടാതെ URI അടങ്ങിയ proxy_pass മൂല്യം പൊരുത്തപ്പെടുന്ന location പ്രിഫിക്സ് എങ്ങനെ മാറ്റിസ്ഥാപിക്കുന്നു എന്നത് മാറ്റുന്നു എന്ന് കുറിക്കുന്നു. ആപ്ലിക്കേഷൻ പ്രതീക്ഷിക്കുന്ന URL പരിശോധിക്കാതെ പാതയുടെ ഘടകങ്ങൾ ചേർക്കുന്നതോ നീക്കുന്നതോ റൂട്ടിംഗ് പരാജയം പോലെ തോന്നുന്ന 404 ഉണ്ടാക്കാനുള്ള വിശ്വസനീയമായ വഴിയാണ്.
proxy_redirect സ്വകാര്യ വിലാസം ചോർത്തുന്ന പ്രതികരണങ്ങൾ തിരുത്തുന്നു
ട്രാഫിക് ഒഴുകാൻ തുടങ്ങിയാൽ, ബാക്കെൻഡ് അതിന്റെ സ്വകാര്യ വിലാസം പേരിടുന്ന ഒരു Location തലക്കെട്ടോടെ ഉത്തരം നൽകിയേക്കാം. ആ തലക്കെട്ട് പിന്തുടരുന്ന ബ്രൗസർ പൊതു പ്രവേശന കേന്ദ്രം വിട്ട്, അതിന് പരിഹരിക്കാനാകാത്ത എന്തിലേക്കോ എത്താൻ ശ്രമിക്കുന്നു. ബോധപൂർവം ക്രമീകരിച്ച പ്രതികരണ പുനരെഴുത്ത് സ്വകാര്യ URL പൊതുവിലേക്ക് മാപ്പ് ചെയ്യുന്നു:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;ഇരുവശവും യഥാർത്ഥ മൂല്യങ്ങളാൽ മാറ്റിസ്ഥാപിക്കുക. ഇടുങ്ങിയ പരിധിയും മനസ്സിലാക്കുക: പൊരുത്തപ്പെടുന്ന Location, Refresh തലക്കെട്ടുകളിലെ വാചകം പുനരെഴുതപ്പെടുന്നു, എന്നാൽ HTML, JavaScript അല്ലെങ്കിൽ ഡൗൺലോഡ് ചെയ്ത ഫയലുകളിൽ ഉൾച്ചേർത്ത URL-കൾ അല്ല.
ഒരു ആപ്ലിക്കേഷൻ എല്ലായിടത്തും കേവല ലിങ്കുകൾ നിർമ്മിക്കുന്നുവെങ്കിൽ, ശാശ്വത പരിഹാരം അതിന്റെ സ്വന്തം ബാഹ്യ-URL ക്രമീകരണമാണ്, പ്രോക്സിയിൽ വളരുന്ന പുനരെഴുത്ത് നിയമങ്ങളുടെ പട്ടികയല്ല. ഔട്ട്പുട്ട് ശരിയായി തോന്നുന്നതുവരെ നിയമങ്ങൾ ചേർക്കുന്നത് ആരും പരിശോധിക്കാത്ത ആദ്യ പേജിൽ പരാജയപ്പെടുന്ന ക്രമീകരണം ഉണ്ടാക്കുന്നു. ആപ്ലിക്കേഷന്റെ ഒരു ശരിയായ ക്രമീകരണം മുഴുവൻ ശേഖരത്തെയും മാറ്റിസ്ഥാപിക്കുന്നു.
തലക്കെട്ട് പുനരെഴുത്തിന് നന്നാക്കാനാകാത്തത്
അടുത്തടുത്തുള്ള നിരവധി പ്രശ്നങ്ങൾ റീഡയറക്ട് പ്രശ്നങ്ങൾ പോലെ തോന്നുന്നു, എന്നാൽ അല്ല. upstream-ലേക്ക് അയക്കുന്ന Host തലക്കെട്ട് ബാക്കെൻഡിന്റെ വെർച്വൽ ഹോസ്റ്റുമായി പൊരുത്തപ്പെടേണ്ടതായേക്കാം. TLS upstream-ന് ഒരു നിർദ്ദിഷ്ട സെർവർ നാമവും സർട്ടിഫിക്കറ്റ് പരിശോധനയും ആവശ്യമായേക്കാം, പ്രതികരണ തലക്കെട്ട് പുനരെഴുത്ത് രണ്ടിനും സഹായിക്കുന്നില്ല.
കുക്കി പരിധിയും ഡൊമെയ്ൻ ആട്രിബ്യൂട്ടുകളും ആപ്ലിക്കേഷനും അതിന്റെ ക്രമീകരണത്തിനും ഉള്ളതാണ്. പ്രോക്സിക്ക് ദിവസം മുഴുവൻ തലക്കെട്ടുകൾ കളയാനോ പുനരെഴുതാനോ കഴിയും, എന്നിട്ടും രണ്ടാം അഭ്യർത്ഥനയിൽ പരാജയപ്പെടുന്ന ഒരു സെഷൻ ഉണ്ടാക്കുന്നു, കാരണം കുക്കി ബ്രൗസർ ഒരിക്കലും സന്ദർശിക്കാത്ത ഒരു ഹോസ്റ്റിന് നൽകിയതായിരുന്നു. ആ പരാജയം ഇടയ്ക്കിടെയുള്ളതായി തോന്നുന്നു, അതുകൊണ്ടാണ് ടിക്കറ്റ് ക്യൂവിൽ ഇത്രയും കാലം നിലനിൽക്കുന്നത്. കുക്കിയുടെ ഡൊമെയ്ൻ വായിക്കുന്നത് സാധാരണയായി ഒരു മിനിറ്റിൽ അന്വേഷണം അവസാനിപ്പിക്കുന്നു.
പ്രാമാണീകരണവും ബാക്കെൻഡ് തിരഞ്ഞെടുക്കലും ഉദ്ദേശിച്ച ആപ്ലിക്കേഷനിൽ പരിമിതപ്പെടുത്തുക. ഒരു പൊതു റിവേഴ്സ് പ്രോക്സി സെർവറിന്റെ VPN വഴി ഒരു ആപ്ലിക്കേഷൻ മാത്രം വെളിപ്പെടുത്തണം, ആ ഹോസ്റ്റിന് എത്താനാകുന്ന ഓരോ സ്വകാര്യ വിലാസത്തിലേക്കുമുള്ള പൊതു ഗേറ്റ്വേ ആകുന്നതിനു പകരം. കോളർ ആവശ്യപ്പെടുന്നതെല്ലാം കൈമാറുന്ന ഒരൊറ്റ പൊതു location ഒരു വെളിപ്പെടുത്തിയ സേവനത്തെ നിങ്ങളുടെ സ്വകാര്യ നെറ്റ്വർക്കിന്റെ ഭൂപടമാക്കി മാറ്റുന്നു. upstream വ്യക്തമായി പേരിടുക, അവിടെത്തന്നെ നിർത്തുക.
അഭ്യർത്ഥന സഞ്ചരിക്കുന്ന ക്രമത്തിൽ പരിശോധിക്കുക
ക്രമമായി മൂന്ന് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: NGINX ഉദ്ദേശിച്ച location തിരഞ്ഞെടുത്തു, ബാക്കെൻഡിലേക്കുള്ള അഭ്യർത്ഥന പൂർത്തിയാക്കി, ബ്രൗസർ പിന്നീടുള്ള ഏതെങ്കിലും റീഡയറക്ട് പിന്തുടർന്ന് ഉപവിഭവങ്ങൾ ലോഡ് ചെയ്തു. ഓരോ ഘട്ടത്തിനും അതിന്റേതായ ലോഗ് വരികളുണ്ട്, അവ ക്രമത്തിൽ വായിക്കുന്നത് അവ്യക്തമായ 502-നെ കൃത്യമായ കണ്ടെത്തലാക്കി മാറ്റുന്നു.
നിങ്ങൾക്ക് വേണ്ട വ്യത്യാസം പരാജയപ്പെട്ട upstream കണക്ഷനും എത്തിച്ചേരാനാകാത്ത സ്വകാര്യ നാമത്തിലേക്ക് അയച്ച ബ്രൗസറും തമ്മിലുള്ളതാണ്. ആദ്യത്തേത് പ്രോക്സി പിശക് ലോഗിൽ പ്രത്യക്ഷപ്പെടുന്നു; രണ്ടാമത്തേത് ഒരിക്കലും വരാത്ത ഒരു അഭ്യർത്ഥനയായി പ്രത്യക്ഷപ്പെടുന്നു, ബ്രൗസർ പരിഹരിക്കാനാകാത്ത ഒരു ഹോസ്റ്റിനെക്കുറിച്ച് പരാതിപ്പെടുന്നു. രണ്ട് വ്യത്യസ്ത പ്രശ്നങ്ങൾ, രണ്ട് വ്യത്യസ്ത ഫയലുകൾ, അവയിൽ ഒന്ന് മാത്രമാണ് proxy_redirect-മായി ബന്ധപ്പെടുന്നത്.