NGINX stream സന്ദർഭത്തിൽ TLS passthrough കണക്ഷൻ അനുവദിക്കുക
TLS അവസാനിപ്പിക്കാതെ തന്നെ NGINX-ന് TCP TLS റിലേ നിരസിക്കാം. അനുമതി നിയമം HTTP location-ൽ അല്ല, stream-ൽ ഇടുക, ഏത് peer വിലാസമാണ് വരുന്നതെന്ന് പരിശോധിക്കുക.
സർട്ടിഫിക്കറ്റ് ഒരിക്കലും കൈവശം വയ്ക്കാതെ എൻക്രിപ്റ്റ് ചെയ്ത ബൈറ്റുകൾ കൈമാറുന്നതാണ് TLS passthrough റിലേ ചെയ്യുന്നത്, ഈ ക്രമീകരണം സൗകര്യപ്രദവും അൽപ്പം ആശയക്കുഴപ്പമുള്ളതുമാണ്. ഒന്നും ഡീക്രിപ്റ്റ് ചെയ്യാത്തതിനാൽ ഫിൽട്ടർ ചെയ്യാൻ HTTP രൂപത്തിൽ ഒന്നുമില്ല, അതിനാൽ സാധാരണ location ബ്ലോക്കും അതിന്റെ ആക്സസ് നിയമങ്ങളും ഇവിടെ ഉപകരിക്കില്ല. NGINX-നുള്ള തീരുമാനം കണക്ഷനെക്കുറിച്ചാണ്: ഏത് നെറ്റ്വർക്ക് peer ആണ് മുട്ടിയത്, ആ peer-നെ ഒട്ടും കൈമാറണമോ എന്നതും.
തീരുമാനം HTTP-യിലല്ല, stream-ൽ ആണ്
stream സന്ദർഭത്തിൽ NGINX TCP സെഷനുകളുമായി പ്രവർത്തിക്കുന്നു. കണക്ഷന്റെ peer വിലാസം കാണുന്നു, ഏതെങ്കിലും ബൈറ്റ് backend-ൽ എത്തുന്നതിന് മുമ്പ് അതിൽ ക്രമമായ allow, deny നിയമങ്ങൾ പ്രയോഗിക്കാനാകും. ഇത് പൂർണ്ണമായ സ്വീകരണ തീരുമാനമാണ്, സ്വകാര്യ കീയോ സർട്ടിഫിക്കറ്റോ HTTP പാഴ്സിംഗോ ആവശ്യമില്ല.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
ആ മൂന്ന് വരികൾ ഒരിക്കലും പരസ്പരം പകരമാകുന്നില്ല. 443 പോർട്ട് പരാമർശിക്കുന്ന ഏത് ഫയലിലും HTTP ആക്സസ് നിർദ്ദേശം പകർത്തുന്നത് ഒന്നും മാറ്റുന്നില്ല, കാരണം stream സെർവർ ഒരിക്കലും http സന്ദർഭം വായിക്കുന്നില്ല.
കൈമാറുന്നതിന് മുമ്പ് കണക്ഷൻ സ്വീകരിക്കുക
stream, stream-access മൊഡ്യൂളുകൾ ലഭ്യമായ നിലവിലുള്ള ഇൻസ്റ്റാളേഷൻ ഉണ്ടെന്ന് കരുതുക, VPN ക്ലയന്റുകൾ ഉറവിട വിലാസങ്ങൾ 10.90.0.0/24-ൽ സൂക്ഷിക്കുന്നു, 192.168.50.20:443-ലെ backend ഇതിനകം ഉദ്ദേശിച്ച HTTPS ഐഡന്റിറ്റി നൽകുന്നു.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷന്റെ നേരിട്ടുള്ള പകരമായല്ല, പുതിയ listener-ന്റെ ഭാഗമായി ഇത് വായിക്കുക. ആദ്യം നിലവിലുള്ള listener-കളും include-കളും പരിശോധിക്കുക, കാരണം ഇതിനകം ബന്ധിച്ച പോർട്ടിലെ രണ്ടാമത്തെ listener അഭ്യർത്ഥനാ സമയത്തല്ല, reload സമയത്താണ് പരാജയപ്പെടുന്നത്.
എന്താണ് ഇല്ലാത്തതെന്ന് ശ്രദ്ധിക്കുക: listen ... ssl ഇല്ല, സർട്ടിഫിക്കറ്റ് നിർദ്ദേശമില്ല. NGINX എൻക്രിപ്റ്റ് ചെയ്ത സ്ട്രീം കൈമാറുന്നു, backend TLS അവസാനിപ്പിച്ച് ക്ലയന്റ് സാധൂകരിക്കുന്ന സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു. allowlist-ൽ പരാജയപ്പെടുന്ന ക്ലയന്റിന്റെ TCP സെഷൻ നിരസിക്കപ്പെടും, HTTP 403 പേജല്ല, സ്റ്റാറ്റസ് കോഡ് പ്രതീക്ഷിക്കുന്ന ഏത് ഉപകരണവും ഉപയോഗശൂന്യമായ എന്തോ റിപ്പോർട്ട് ചെയ്യും.
allowlist എന്ത് ഉൾക്കൊള്ളുന്നു, എന്ത് ഇല്ല
റിലേ ഇതിനകം സെർവർ നാമം അനുസരിച്ച് backend തിരഞ്ഞെടുക്കുന്നുവെങ്കിൽ, മൊഡ്യൂൾ ലഭ്യമാണെങ്കിൽ ssl_preread-നും map-നും ആ ജോലി തുടരാം. പേര് ഇപ്പോഴും ക്ലയന്റ് നൽകുന്നു, പേര് അവതരിപ്പിക്കുന്നത് ക്ലയന്റ് VPN-ൽ ചേർന്നു എന്ന് തെളിയിക്കുന്നില്ല.
ഉദാഹരണ നിയമം മുഴുവൻ stream listener-നെയും ഉൾക്കൊള്ളുന്നു. അതിനാൽ പൊതു സൈറ്റുകളുടെയും VPN-മാത്രം സൈറ്റുകളുടെയും മിശ്രിതം നൽകുന്ന ഒരു പ്രവേശന കേന്ദ്രത്തിന് ഇത് അനുയോജ്യമല്ല, അവിടെ ഓരോ പേരിനും ഒഴിവാക്കൽ വേണം; ആർക്കും വായിക്കാനാകാത്ത പേരിനെ ആശ്രയിക്കുന്ന നയത്തേക്കാൾ വേർതിരിച്ച listener-കൾ സാധാരണയായി വ്യക്തമാണ്.
രണ്ട് കൂടുതൽ വിടവുകൾ പറയേണ്ടതുണ്ട്. prefix പൊരുത്തം പാക്കറ്റ് ഏത് ഇന്റർഫേസിൽ നിന്ന് വന്നു എന്ന് പറയുന്നില്ല, മറ്റൊരിടത്തെ HTTP നിയമത്തിന് ഈ listener-നെ നിയന്ത്രിക്കാനാകില്ല. രണ്ടും ഒരു allow വരിയെ മുഴുവൻ അതിർത്തിയായി കാണുന്നതിന് പകരം ഹോസ്റ്റ് തലത്തിലുള്ള ingress നയം ചിത്രത്തിൽ നിലനിർത്താനുള്ള കാരണങ്ങളാണ്. അതിർത്തി യോജിക്കേണ്ട രണ്ട് നിയന്ത്രണങ്ങളായി എഴുതുക, ഏതെങ്കിലും ഒന്നിലെ മാറ്റം അവലോകനം ചെയ്യപ്പെടാൻ.
NGINX യഥാർത്ഥത്തിൽ ആരുടെ വിലാസമാണ് കാണുന്നത്?
ലോഡ് ബാലൻസർ, മറ്റൊരു proxy അല്ലെങ്കിൽ source NAT എന്നിവ NGINX-ന്റെ മുന്നിൽ ഒരു ഇടനിലക്കാരനെ വയ്ക്കാം, അതിനാൽ കാണുന്ന peer VPN ക്ലയന്റിന്റെ ആന്തരിക വിലാസമല്ല. prefix തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് യഥാർത്ഥ പാത പരിശോധിക്കുക, തെറ്റായ വിലാസത്തിനായി എഴുതിയ allowlist പരിഭാഷകന്റെ പിന്നിലുള്ള എല്ലാവരെയും അനുവദിക്കും അല്ലെങ്കിൽ ആരെയും അനുവദിക്കില്ല.
PROXY പ്രോട്ടോക്കോളും യഥാർത്ഥ IP കൈകാര്യം ചെയ്യലും നിയമാനുസൃതമായ ഉത്തരങ്ങളാണ്, അവ അനുയോജ്യവും വ്യക്തമായി വിശ്വസിക്കപ്പെട്ടതുമായ അയച്ചയാളുകൾക്ക് മാത്രം ക്രമീകരിക്കണം. രണ്ട് സംവിധാനങ്ങളും അയച്ചയാൾ പറയുന്നത് വിശ്വസിക്കുന്നു, അതുകൊണ്ടാണ് അയച്ചയാളുകളുടെ പട്ടിക ചെറുതായിരിക്കേണ്ടത്. ഏതെങ്കിലും ഇന്റർനെറ്റ് ക്ലയന്റിൽ നിന്നുള്ള ഐഡന്റിറ്റി ഹെഡർ വിശ്വസിക്കുന്നത് ഉറവിട വിവരങ്ങളെ വീണ്ടും വിശ്വസനീയമാക്കുന്നില്ല; അത് ശരിയായ നിരസിക്കലിനെ വ്യാജ സ്വീകരണമാക്കി മാറ്റുന്നു.
reload-ന് മുമ്പ് രണ്ട് ഫലങ്ങളും പരിശോധിക്കുക
കോൺഫിഗറേഷൻ സാധൂകരിച്ച് reload ചെയ്യുക, പിന്നീട് രണ്ട് തവണ പരിശോധിക്കുക: പ്രവർത്തിക്കേണ്ട പുതിയ അനുവദിച്ച സെഷൻ, പ്രവർത്തിക്കരുതാത്ത നിരസിച്ച ഒന്ന്. അനുവദിച്ച പരിശോധനയിൽ സാധാരണ backend സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണം നിലനിർത്തുക, കാരണം ബന്ധിപ്പിക്കുന്നുവെങ്കിലും backend സാധൂകരിക്കാനാകാത്ത റിലേ ഒരു പ്രശ്നം പരിഹരിച്ച് മറ്റൊന്ന് സൃഷ്ടിച്ചു.
nginx -t
ss -tnp | grep ':443'backend പാതയും പ്രതികരണവും വെവ്വേറെ പരിശോധിക്കുക. allowlist കടക്കുന്നത് NGINX സെഷൻ സ്വീകരിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു; എത്തിച്ചേരാനാകാത്ത backend-നെ പ്രതികരിപ്പിക്കാൻ കഴിയില്ല, നിങ്ങൾ തുടങ്ങുന്നതിന് മുമ്പ് ഇല്ലാതിരുന്ന മടക്ക പാത ശരിയാക്കാനും കഴിയില്ല.