VPN-നായി മാത്രമുള്ള NGINX സൈറ്റ്: ലിസണർ, ഫയർവാൾ, HTTP അനുമതി പട്ടിക

സ്വകാര്യ സൈറ്റും ഇന്റർനെറ്റും തമ്മിൽ മൂന്ന് സ്വതന്ത്ര തീരുമാനങ്ങൾ നിൽക്കുന്നു: ഏത് സോക്കറ്റ് കണക്ഷൻ സ്വീകരിക്കുന്നു, ഏത് പാത അത് എത്തിക്കാം, തിരഞ്ഞെടുത്ത സർവർ ഏത് HTTP ക്ലയന്റുകൾക്ക് മറുപടി നൽകുന്നു. സർവർ ബ്ലോക്ക് ആദ്യ തീരുമാനം മാത്രം എടുക്കുന്നു. ബാക്കി രണ്ടിനെ വേറിട്ട നിയന്ത്രണങ്ങളായി കാണുക, അല്ലെങ്കിൽ സൈറ്റ് സ്വകാര്യമായി തോന്നും പക്ഷേ പഴയ പ്രവേശനം തുറന്നിരിക്കും. VPN-നായി മാത്രമുള്ള NGINX പരാജയങ്ങളിൽ ഭൂരിഭാഗവും ആദ്യ പാളി മാത്രം പരിശോധിക്കുന്നതിൽ നിന്ന് വരുന്നു.

ഉദാഹരണം tun0-ൽ 10.90.0.1-ൽ Linux OpenVPN ഗേറ്റ്‌വേ, 10.90.0.0/24-ൽ ക്ലയന്റുകൾ, സംരക്ഷിത ഉറവിടങ്ങൾ, ഈ പ്രവേശനത്തിനായി നീക്കിവച്ച TCP 8443 എന്നിവ ഉപയോഗിക്കുന്നു. മൂല്യങ്ങൾ ക്രമീകരിക്കുക, പാളികൾ നിലനിർത്തുക.

ഹോസ്റ്റ്നാമിൽ നിന്നല്ല, സോക്കറ്റിൽ നിന്ന് തുടങ്ങുക

HTTPS ലിസണറെ ടണൽ വിലാസത്തിലും പ്രത്യേക പോർട്ടിലും ബന്ധിക്കുക. വൈൽഡ്കാർഡ് സോക്കറ്റും പേര് പരിശോധനയും ചേർന്നതിനേക്കാൾ നിർദ്ദിഷ്ട വിലാസത്തെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പമാണ്, കാരണം കർണൽ പോർട്ട് മറ്റൊരു ലോക്കൽ വിലാസത്തിന് നൽകില്ല.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

ക്ലയന്റുകൾ ടൈപ്പ് ചെയ്യുന്ന സേവന ഹോസ്റ്റ്നാമം സർട്ടിഫിക്കറ്റിൽ ഉണ്ടായിരിക്കണം, സ്വകാര്യ DNS കാഴ്ച ആ ഹോസ്റ്റിനെ ബന്ധിച്ച വിലാസത്തിലേക്ക് പരിഹരിക്കണം. server_name വെർച്വൽ ഹോസ്റ്റ് മാത്രം തിരഞ്ഞെടുക്കുന്നു; അത് ആരെയും പ്രാമാണീകരിക്കുന്നില്ല. DNS എൻട്രി ഇല്ലെങ്കിൽ TLS തകരാറിനെപ്പോലെ തോന്നുന്ന സർട്ടിഫിക്കറ്റ് പിശക് ഉണ്ടാകും. സർട്ടിഫിക്കറ്റ് മാറ്റുന്നതിന് മുമ്പ് പേര് പരിശോധിക്കുക.

ഫയൽ ചേർക്കുന്നതിന് മുമ്പ് ഫലപ്രദമായ കോൺഫിഗറേഷൻ വായിക്കുക. ഇൻക്ലൂഡുകളും വൈൽഡ്കാർഡ് ലിസണറുകളും അതേ റൂട്ട് മറ്റെവിടെയെങ്കിലും നൽകാം, ഡിഫോൾട്ട് സർവർ പുതിയ ബ്ലോക്ക് ഒരിക്കലും കാണാത്ത അഭ്യർത്ഥനകൾക്ക് മറുപടി നൽകാം.

ആ ഉള്ളടക്കത്തിനായി മറ്റെല്ലാ ലിസണറുകളും അടയ്ക്കുക

listen നിർദ്ദേശങ്ങൾ ലിസ്റ്റ് ചെയ്ത് അവ നൽകുന്ന റൂട്ടുകൾ താരതമ്യം ചെയ്യുക. മറ്റൊരു ആപ്പിനായി ചേർത്ത ബ്ലോക്ക് അതേ upstream-ലേക്ക് പ്രോക്സി ചെയ്യാം, പഴയ ഡിഫോൾട്ട് സർവർ പുതിയത് സ്ഥാപിച്ചതിന് ശേഷവും മറുപടി നൽകാം. ആ ഔട്ട്പുട്ടാണ് യഥാർത്ഥ ഇൻവെന്ററി, ഇപ്പോൾ തിരുത്തിയ ഫയലല്ല. ഒരേ ഉള്ളടക്കം നൽകുന്ന ഓരോ റൂട്ടും താരതമ്യം ചെയ്യുക.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

രണ്ട് വിലാസ കുടുംബങ്ങളും പരിശോധിക്കുക. IPv4 ബൈൻഡ് IPv6 സോക്കറ്റിനെ തൊടാതെ വിടുന്നു, പുതിയ A റെക്കോർഡ് ഇപ്പോഴും പൊതു പാതയിലേക്ക് ചൂണ്ടുന്ന പഴയ AAAA മറുപടി പിൻവലിക്കുന്നില്ല.

പഴയ വെർച്വൽ ഹോസ്റ്റ് പ്രത്യേക മാറ്റമായി പിൻവലിക്കുക. പുതിയ ബ്ലോക്കിന്റെ പൊതു ഇരട്ടയെ നീക്കം ചെയ്യുന്നതാണ് സാധാരണയായി പ്രവേശനം യഥാർത്ഥത്തിൽ അടയ്ക്കുന്ന ഘട്ടം; സ്വകാര്യ ലിസണർ ഉദ്ദേശിച്ചത് മാത്രം ചേർക്കുന്നു.

ഹോസ്റ്റിൽ വരുന്ന പാതയുടെ പരിധി നിശ്ചയിക്കുക

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

സ്ഥിരസ്ഥിതി നിരസിക്കുന്ന ഇൻകമിംഗ് നയവും ഈ സേവനത്തിന് വിശാലമായ അനുമതിയും ഇല്ലാത്തപ്പോൾ, പരിമിത നിയമം ടണൽ, ഉറവിട ശ്രേണി, ലക്ഷ്യം, പോർട്ട് എന്നിവ ഒരുമിച്ച് പേരിടുന്നു:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

പ്രയോഗിക്കുന്നതിന് മുമ്പ് ഫലപ്രദമായ ഫയർവാൾ ക്രമം വായിക്കുക. മുൻപത്തെ വിശാല സ്വീകരണം നിയന്ത്രണത്തെ പരാജയപ്പെടുത്താം, മുൻപത്തെ അന്തിമ ഡ്രോപ്പ് ഈ അനുമതി എത്തുന്നത് തടയാം. ഉദാഹരണം യോജിക്കാൻ ബന്ധമില്ലാത്ത നിയമങ്ങൾ ഫ്ലഷ് ചെയ്യരുത്, ഫയർവാൾ ഓഫ് ചെയ്യരുത്.

ആ നിയമം ഹോസ്റ്റ് ഇൻപുട്ടാണ്, മറ്റൊരു LAN മെഷീനിലേക്കുള്ള റൂട്ടല്ല, ഗേറ്റ്‌വേയുടെ പുറം OpenVPN ലിസണർ പ്രത്യേക സേവനമായി തുടരുന്നു. സൈറ്റ് മുമ്പ് പൊതുവായിരുന്നെങ്കിൽ, പഴയ പ്രവേശനം എങ്ങനെ പിൻവലിക്കാം, നിലവിലുള്ള സെഷനുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യാം എന്ന് ആസൂത്രണം ചെയ്യുക.

സ്ഥലങ്ങൾ മാറുമ്പോൾ HTTP പട്ടിക കേടുപാടില്ലാതെ സൂക്ഷിക്കുക

NGINX allow, deny എൻട്രികൾ ക്രമത്തിൽ വിലയിരുത്തുന്നു, മുകളിലെ സർവർ തല പട്ടിക അന്തിമ deny-യ്ക്ക് മുമ്പ് പ്രഖ്യാപിത കൂട്ടത്തെ അനുവദിക്കുന്നു. ഏതെങ്കിലും ആക്സസ് എൻട്രി നിർവചിക്കുന്ന സ്ഥലം മാതൃ പട്ടികയ്ക്ക് പകരം സ്വന്തം പട്ടിക ഉപയോഗിക്കുന്നു എന്നും ആക്സസ് മൊഡ്യൂൾ രേഖപ്പെടുത്തുന്നു. ക്രമം എൻട്രികൾക്ക് തുല്യം പ്രധാനമാണ്.

ആ റീസെറ്റാണ് സാധാരണ റിഗ്രഷൻ. ഒരു എൻട്രി ചേർക്കുന്ന പുതിയ അപ്‌ലോഡ്, API അല്ലെങ്കിൽ ആരോഗ്യ സ്ഥലം സർവർ തല നിയന്ത്രണത്തെ നിശബ്ദമായി മാറ്റിസ്ഥാപിക്കുന്നു, സൈറ്റ് ഏറ്റവും അടുത്തിടെ ചേർത്ത പാതയിൽ വിശാലമാകുന്നു.

ഓരോ സ്ഥലവും അലിയാസും ഇതര ബ്ലോക്കും ഒരേ നയത്തിന്റെ ഭാഗമായി പരിശോധിക്കുക. IP പരിശോധനകൾ NGINX പ്രാമാണീകരണവുമായി ചേർന്നാൽ, satisfy മനസ്സിലാക്കുക: any ക്രമീകരണം ഒരു സംവിധാനത്തിലൂടെ ക്ലയന്റിനെ കടത്തിവിടാം, മറ്റൊന്ന് ഇതുവരെ കടന്നിട്ടില്ലെങ്കിലും. ആക്സസ് പട്ടിക സ്ഥല പരിശോധന ചെക്ക്‌ലിസ്റ്റിൽ ചേർക്കുക.

TCP കണക്ഷൻ NGINX-ൽ എത്തിയതിന് ശേഷമാണ് HTTP നിരസിക്കൽ സംഭവിക്കുന്നത്. അത് നെറ്റ്‌വർക്ക് നിയന്ത്രണത്തെ പൂരകമാക്കുന്നു, ആപ്പിന്റെ സ്വന്തം അധികാരം ഓരോ ഉപയോക്താവിനും ഇപ്പോഴും ബാധകമാണ്.

ജീവനുള്ള പാതയും പരാജയ സാഹചര്യവും പരിശോധിക്കുക

കോൺഫിഗറേഷൻ പാർസർ പ്രവർത്തിപ്പിക്കുക, ശ്രവിക്കുന്ന സോക്കറ്റുകൾ പരിശോധിക്കുക, തുടർന്ന് ഉദ്ദേശിച്ച ക്ലയന്റിൽ നിന്ന് പുതിയ പേരുള്ള അഭ്യർത്ഥന നടത്തുക. സർട്ടിഫിക്കറ്റ് സാധുവാണെന്ന്, DNS നാമം ബന്ധിച്ച വിലാസത്തിലേക്ക് പരിഹരിക്കുന്നു എന്ന്, പ്രതികരണം പ്രതീക്ഷിച്ച റൂട്ടിൽ നിന്ന് വരുന്നു എന്ന് ഉറപ്പാക്കുക.

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

ബൂട്ട് അല്ലെങ്കിൽ VPN വീണ്ടെടുക്കൽ സാഹചര്യം ആവർത്തിക്കുക. ടണൽ വിലാസം നിലവിൽ വരുന്നതിന് മുമ്പ് NGINX ആരംഭിച്ചാൽ, തികഞ്ഞ ഫയൽ ഉണ്ടായാലും ബൈൻഡിംഗ് പരാജയപ്പെടാം. വിലാസ സന്നദ്ധത ഏകോപിപ്പിക്കുക, പങ്കിട്ട വെബ് സർവർ മാറ്റുന്നതിന് മുമ്പ് പ്രാദേശിക വീണ്ടെടുക്കൽ പാത സൂക്ഷിക്കുക.

വിജയിച്ച സോക്കറ്റ്, പോർട്ട്, ഉറവിട ശ്രേണി, HTTP പട്ടിക എന്നിവ രേഖപ്പെടുത്തുക. അടുത്ത VPN അല്ലെങ്കിൽ DNS മാറ്റം അവയിലേതെങ്കിലും നീക്കാം, പ്രവർത്തിക്കുന്ന ബ്രൗസർ ടാബിനേക്കാൾ നാല് പേരുള്ള മൂല്യങ്ങൾ താരതമ്യം ചെയ്യാൻ എളുപ്പമാണ്.