മുന്നിൽ Nginx, VPN പിന്നിൽ സ്വകാര്യ ബാക്ക്എൻഡ്

ബ്രൗസർ Nginx-നോട് സംസാരിക്കുന്നു, Nginx ടണലിൽ രണ്ടാമത്തെ കണക്ഷൻ തുറക്കുന്നു. രണ്ടും റൂട്ട് ചെയ്യുക, രണ്ട് സർട്ടിഫിക്കറ്റുകളും പരിശോധിക്കുക, പൊതു റീഡയറക്ടുകൾ പൊതുവായി നിലനിർത്തുക.

ട്രെയിനിലുള്ള ഫോണിൽ നിന്ന് ഒരു അഭ്യർത്ഥന സ്വകാര്യ നെറ്റ്വർക്കിനുള്ളിൽ മാത്രം നിലനിൽക്കുന്ന ബാക്ക്എൻഡ് വരെ ട്രാക്ക് ചെയ്യുക. ഫോൺ ഒരു പൊതു പേര് റിസോൾവ് ചെയ്യുന്നു, പോർട്ട് 443-ലെ പൊതു വിലാസത്തിലേക്ക് കണക്ട് ചെയ്യുന്നു, സാധാരണ TLS ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കുന്നു. Nginx ആ കണക്ഷൻ സ്വീകരിക്കുന്നു, പിന്നീട് VPN ഇന്റർഫേസ് വഴി മാത്രം എത്തുന്ന വിലാസത്തിലേക്ക് രണ്ടാമത്തെ, പൂർണ്ണമായി വേറിട്ട കണക്ഷൻ തുറക്കുന്നു. ഫോണിൽ ഒന്നും മാറുന്നില്ല, ഒരു ടണൽ ഉൾപ്പെട്ടിരുന്നു എന്ന് ഫോണിന് ഒരിക്കലും അറിയില്ല.

ഒരു അഭ്യർത്ഥന രണ്ട് കണക്ഷനുകളിലൂടെ പിന്തുടരുന്നത്

ഉള്ളിലേക്ക് വരുന്ന ഭാഗം ഒരു പൊതു HTTP ഇടപാടാണ്. അതിന് ഒരു പൊതു പേര്, ഒരു പൊതു സർട്ടിഫിക്കറ്റ്, ആ നിമിഷത്തിൽ സന്ദർശകനുള്ള ഏത് വിലാസത്തിനും പ്രവർത്തിക്കേണ്ട ഒരു മറുപടി പാത എന്നിവയുണ്ട്. ആ പാതയെ തകരാറിലാക്കുന്ന ഏത് മാറ്റവും എല്ലാ സന്ദർശകരെയും ഒരുമിച്ച് തകർക്കുന്നു. അതുകൊണ്ടാണ് പൊതു ഭാഗം നിങ്ങൾ ഏറ്റവും കുറച്ച് പരീക്ഷണം നടത്താൻ ആഗ്രഹിക്കുന്ന ഭാഗം.

പുറത്തേക്ക് പോകുന്ന ഭാഗം സ്വകാര്യമാണ്. Nginx ക്ലയന്റ് ആകുന്നു, ഒരു ആന്തരിക പേര് റിസോൾവ് ചെയ്യുന്നു അല്ലെങ്കിൽ സ്ഥിര വിലാസം ഉപയോഗിക്കുന്നു, ഇന്റർനെറ്റിൽ നിന്ന് വരുന്ന കണക്ഷൻ നിരസിക്കുന്ന ഒരു സേവനത്തിൽ എത്തുന്നു.

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

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

ഇതിൽ എന്തെങ്കിലും നിർമ്മിക്കുന്നതിന് മുമ്പ്, അപ്ലിക്കേഷൻ പ്രസിദ്ധീകരിക്കുന്നത് ഉദ്ദേശ്യപൂർവമാണെന്ന് സ്ഥിരീകരിക്കുക. പ്രവർത്തിക്കുന്ന ഒരു പ്രോക്സി പ്രവർത്തിക്കുന്ന ഒരു വെളിപ്പെടുത്തലുമാണ്, ഒപ്പം പ്രാമാണീകരണ മാതൃക ഒരു തീരുമാനമായിരിക്കണം, പാർശ്വഫലമല്ല.

ഗേറ്റ്‌വേയുടെ പേര് ടണലിൽ നിന്ന് അതിജീവിക്കണം

പേര് റിസോൾവിംഗിൽ ഒരു സൂക്ഷ്മമായ കെണിയുണ്ട്. സ്വകാര്യ DNS, VPN പ്രൊഫൈൽ തന്റെ ഗേറ്റ്‌വേയ്ക്കായി ഉപയോഗിക്കുന്ന അതേ പേര് തന്നെ മാറ്റിയെഴുതുന്നെങ്കിൽ, വീണ്ടും കണക്ട് ചെയ്യൽ അവസാനം താൻ തന്നെ സൃഷ്ടിക്കേണ്ട ടണലിലൂടെ ആ ഗേറ്റ്‌വേയിൽ എത്താൻ ശ്രമിച്ചേക്കാം. ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പേ ആ പേര് റിസോൾവ് ചെയ്യപ്പെട്ടിരിക്കണം. ഒരിക്കൽ അത് ടണലിനുള്ളിൽ റിസോൾവ് ചെയ്യപ്പെട്ടാൽ, കണക്ഷൻ ഒരിക്കലും നിർമ്മിക്കാനാവില്ല.

ഗേറ്റ്‌വേയ്ക്കും ബാക്ക്എൻഡിനും വെവ്വേറെ അംഗീകൃത പേരുകൾ ഉപയോഗിക്കുക, ഓരോ പേരും അതിന്റെ ഉപഭോക്താവിന് ആവശ്യമായ വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യപ്പെടുന്ന വിധത്തിൽ റിസോൾവർ നയം പരിമിതപ്പെടുത്തുക. ഏതെങ്കിലും അപ്ലിക്കേഷന്റെ Host ഹെഡർ മാറ്റുന്നത് ഇവിടെ ഒന്നും ചെയ്യുന്നില്ല, കാരണം തിരച്ചിൽ നടത്തുന്നത് VPN ക്ലയന്റാണ്.

പിന്നീട് പരിധിയെക്കുറിച്ച് ചിന്തിക്കുക. ഫ്രണ്ട്എൻഡിന് ബാക്ക്എൻഡിന്റെ വിലാസത്തിലേക്ക് ഒരു റൂട്ട് വേണം, ഒപ്പം പൊതു ക്ലയന്റുകൾക്ക് ഉത്തരം നൽകുന്നത് തുടരണം. ആ ഹോസ്റ്റിലെ പൂർണ്ണ ടണൽ ആദ്യ ആവശ്യകത നിറവേറ്റി രണ്ടാമത്തേത് തകർത്തേക്കാം.

നയം അനുവദിക്കുന്നിടത്ത്, ഒരു നിർദ്ദിഷ്ട ലക്ഷ്യത്തിലേക്കുള്ള ടണൽ കൂടുതൽ വ്യക്തമായ രൂപകൽപ്പനയാണ്. നയം പൂർണ്ണ ടണൽ നിർബന്ധമാക്കുന്നിടത്ത്, ഫ്രണ്ട്എൻഡ് പ്രത്യേക നെറ്റ്വർക്ക് സന്ദർഭത്തിലായിരിക്കണം, അറിയപ്പെടുന്ന സന്ദർശകർക്കുവേണ്ടി താൽക്കാലിക റൂട്ടുകൾ കൊണ്ട് ഒട്ടിക്കരുത്.

സർവർ ബ്ലോക്ക് രണ്ട് ഭാഗങ്ങളും പരിശോധിക്കുന്ന വിധത്തിൽ എഴുതുക

ബാക്ക്എൻഡ് ഈ പേരിന് ഒരു സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു എന്ന് കരുതുക: backend.corp.example കൂടാതെ സ്വകാര്യ വിലാസത്തിൽ മറുപടി നൽകുന്നു. ഒരു പേര് പരിശോധിക്കുമ്പോൾ ഒരു വിലാസത്തിലേക്ക് കണക്ട് ചെയ്യുന്നത് പ്രോക്സി മൊഡ്യൂളിന്റെ SNI, പേര് ഓപ്ഷനുകൾ എന്നിവയുടെ കൃത്യമായ ഉദ്ദേശ്യമാണ്.

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

മുകളിലെ ഓരോ പാതയും വിലാസവും ഒരു പ്ലേസ്ഹോൾഡറാണ്. പ്രധാനമായത് പരിശോധന ഓണായി നിർത്തുന്ന ഭാഗങ്ങളാണ്: പരിശോധിക്കാനുള്ള ഒരു പേര്, അതിനെതിരെ പരിശോധിക്കാനുള്ള ഒരു ട്രസ്റ്റ് ബണ്ടിൽ, അംഗീകൃത ശൃംഖലയുമായി യോജിക്കുന്ന ആഴം.

proxy_set_header Host app.example.com ഉദ്ദേശ്യപൂർവമാണ്. ബാക്ക്എൻഡ് ആ പൊതു ഉത്ഭവം സ്വീകരിക്കാൻ കോൺഫിഗർ ചെയ്യണം, ഈ ഫ്രണ്ട്എൻഡിൽ നിന്ന് മാത്രം ഫോർവേഡ് ചെയ്ത ഹെഡറുകളിൽ വിശ്വസിക്കണം. അതിന് മുകളിൽ എഴുതുന്നത് X-Forwarded-For ക്ലയന്റ് വിലാസത്തോടെ ഒരു പ്രോക്സിക്ക് ശരിയും ഒരു ശൃംഖലയ്ക്ക് തെറ്റുമാണ്, അതിനാൽ ബഹു-പ്രോക്സി വിന്യാസത്തിന് സ്വന്തം വിശ്വസ്ത വിലാസ ക്രമീകരണം വേണം.

പൊതു ഉത്ഭവത്തെ പൊതു ഉത്ഭവം പോലെ പെരുമാറാൻ പ്രേരിപ്പിക്കുക

അപ്ലിക്കേഷൻ പൊതു ഉത്ഭവത്തിനായി കേവല URL-കൾ, റീഡയറക്ടുകൾ, കുക്കികൾ എന്നിവ പുറപ്പെടുവിക്കണം. അത് ഒരു സന്ദർശകനെ ഇവിടേക്ക് റീഡയറക്ട് ചെയ്താൽ: backend.corp.example, ആ സന്ദർശകൻ റിസോൾവ് ചെയ്യാനാവാത്ത ഒരു പേരിലേക്ക് അയക്കപ്പെടുന്നു.

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

കുക്കികളും അതേ പരിചരണത്തിന് അർഹമാണ്. സ്വകാര്യ പേരിൽ പരിമിതപ്പെടുത്തിയ കുക്കി പൊതു പേര് മാത്രം അറിയാവുന്ന ബ്രൗസർ ഒരിക്കലും അയക്കില്ല.

Nginx യഥാർത്ഥത്തിൽ പൊതു സോക്കറ്റ് കൈവശം വയ്ക്കാനാകുമോ എന്നും സ്ഥിരീകരിക്കുക. 443-ൽ നിലവിലുള്ള വെബ് സേവനം നീങ്ങണം അല്ലെങ്കിൽ ഫ്രണ്ട്എൻഡ് മറ്റെവിടെയെങ്കിലും ആയിരിക്കണം, കാരണം രണ്ട് പ്രോസസുകൾക്ക് ഒരേ വിലാസവും പോർട്ടും ബൈൻഡ് ചെയ്യാനാവില്ല.

ഓരോ ഭാഗവും അത് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നിടത്ത് തന്നെ പരിശോധിക്കുക

ഏതെങ്കിലും റീലോഡിന് മുമ്പ് കോൺഫിഗറേഷൻ ഇൻസ്റ്റാൾ ചെയ്ത പാർസർ ഉപയോഗിച്ച് സാധുവാക്കുക, ടൈപ്പിംഗ് പിശക് ഇപ്പോൾ സേവനം നൽകുന്ന ശ്രോതാവിനെ വീഴ്ത്താതിരിക്കാൻ.

പിന്നീട് ബാക്ക്എൻഡ് ഭാഗം ഫ്രണ്ട്എൻഡ് ഹോസ്റ്റിൽ നിന്ന് തന്നെ, Nginx ഉപയോഗിക്കുന്ന അതേ നെറ്റ്വർക്ക് സന്ദർഭത്തിൽ പരീക്ഷിക്കുക. ടണലിലൂടെയുള്ള ping എത്തിച്ചേരൽ തെളിയിക്കുന്നു, TLS, അധികാരം അല്ലെങ്കിൽ അപ്ലിക്കേഷൻ സംബന്ധിച്ച് ഒന്നുമല്ല.

അവസാനം യഥാർത്ഥ ഹോസ്റ്റ് പേരിലേക്ക് സാധാരണ സർട്ടിഫിക്കറ്റ് പരിശോധനയോടെ പുതിയ പൊതു അഭ്യർത്ഥന അയക്കുക, മറുപടി ബോഡി മാത്രമല്ല മറുപടി പാതയും നിരീക്ഷിക്കുക.

രണ്ട് നിരീക്ഷണങ്ങളും വിന്യസിച്ച കോൺഫിഗറേഷനൊപ്പം സൂക്ഷിക്കുക, ടണൽ ലഭ്യമല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് രേഖപ്പെടുത്തുക. ഫ്രണ്ട്എൻഡ് നിയന്ത്രിത upstream പിശക് തിരികെ നൽകണം, ആരും രേഖപ്പെടുത്താത്ത മറ്റൊരു ബാക്ക്എൻഡിലേക്ക് നിശ്ശബ്ദമായി വീഴരുത്. വ്യക്തമായ ലോഗ് വരിയോടെയുള്ള 502 നല്ല ഫലമാണ്. അനുദ്ദേശ്യ ഉത്ഭവത്തിൽ നിന്ന് കാഷ് ചെയ്ത പേജ് അങ്ങനെയല്ല.

അനുബന്ധ ലേഖനങ്ങൾ