HAProxy 302 ഒരു സ്വകാര്യ ആപ്പിലേക്ക്: രണ്ടാം ഹോപ്പ് ആര് തുറക്കുന്നു?

ഒരു റീഡയറക്ട് രണ്ടാം കണക്ഷൻ ബ്രൗസറിന് തിരികെ നൽകുന്നു. പകരം അഭ്യർത്ഥന backend-ലേക്ക് അയക്കുക, പിന്നീട് ആപ്പിന്റെ സ്വന്തം കേവല റീഡയറക്ടുകളും കുക്കികളും ശരിയാക്കുക.

ആരോ ഒരു പൊതു HAProxy ഹോസ്റ്റ് ആന്തരിക ആപ്ലിക്കേഷനിലേക്ക് തിരിക്കുന്നു, ബ്രൗസർ എന്തുകൊണ്ട് പിന്തുടരാനാകുന്നില്ലെന്ന് ചോദിക്കുന്നു. പ്രോക്സി തന്റെ VPN വഴി ആപ്പിലെത്തുന്നു, റീഡയറക്ട് ഒരു Location ഹെഡർ തിരികെ നൽകുന്നു, ബ്രൗസർ പിന്നീട് ടണലിനുള്ളിൽ മാത്രമുള്ള ഒരു വിലാസം ശ്രമിക്കുന്നു. പുറത്തുനിന്ന് പേജ് വെറുതെ തൂങ്ങിക്കിടക്കുന്നു. രണ്ടാം കണക്ഷൻ ഏത് വശം തുറക്കുന്നു എന്നതാണ് തീരുമാനം, അതാണ് റീഡയറക്ടിനെ backend-ൽ നിന്ന് വേർതിരിക്കുന്നത്.

കോൺഫിഗറേഷനിൽ സമാനമായി കാണുന്ന രണ്ട് പാതകൾ

റീഡയറക്ട് ഒരു പ്രതികരണത്തോടെ കൈമാറ്റം അവസാനിപ്പിക്കുന്നു. ക്ലയന്റ് Location വായിച്ച്, താൻ ഇരിക്കുന്നിടത്തുനിന്ന് പുതിയ അഭ്യർത്ഥന തുടങ്ങുന്നു, അതായത് നിങ്ങൾ ഒരിക്കലും നിയന്ത്രിക്കാത്ത നെറ്റ്വർക്കിൽ നിന്ന്. പ്രോക്സി ഇനി പങ്കെടുക്കുന്നില്ല. തുടർന്നുള്ളതെല്ലാം ക്ലയന്റിന്റെ സ്വന്തം DNS, റൂട്ട്, വിശ്വാസം എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഉപയോക്താവ് ബ്രൗസർ എവിടെ തുറന്നു എന്നതനുസരിച്ച് ഫലം മാറുന്നു:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

പ്രോക്സിയുടെ backend രണ്ടാം ഘട്ടം സെർവർ വശത്ത് നിർത്തുന്നു. പ്രോക്സി അത് ഇതിനകം ഉള്ള പാതയിലൂടെ തുറക്കുന്നു, ക്ലയന്റ് ഒരു പൊതു നാമവുമായി സംസാരിക്കുന്നത് തുടരുന്നു. ടണൽ വീണാൽ, ക്ലയന്റിന് പിന്തുടരാനാകാത്ത URL-നു പകരം പിശക് ലഭിക്കുന്നു. ഈ വ്യത്യാസമാണ് പരാജയത്തെ രോഗനിർണയയോഗ്യമാക്കുന്നത്, കാരണം പിശക് ലോഗുകൾ ഉള്ളിടത്ത് പ്രത്യക്ഷപ്പെടുന്നു:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy-യുടെ റീഡയറക്ട് ഡോക്യുമെന്റേഷൻ കൃത്യമായി ഈ രേഖ വരയ്ക്കുന്നു: ക്ലയന്റിന് റീഡയറക്ടിലൂടെ ഉത്തരം നൽകുന്നത് അഭ്യർത്ഥന backend-ലേക്ക് അയക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത പ്രവർത്തിയാണ്. രണ്ട് നിർദ്ദേശങ്ങളും കോൺഫിഗറേഷൻ ഫയലിൽ കുറച്ച് വരികൾ അകലെയാണ്, തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. ഒന്ന് അഭ്യർത്ഥന അവസാനിപ്പിക്കുന്നു, മറ്റൊന്ന് പ്രോക്സിക്ക് സ്വന്തമായ രണ്ടാമത്തേത് തുടങ്ങുന്നു.

ബ്രൗസറിന് എന്ത് വേണം, സെർവറിന്റെ VPN എന്ത് നൽകുന്നില്ല

ബ്രൗസറിന്റെ സ്വന്തം അഭ്യർത്ഥനയ്ക്ക് അതിന് ഇല്ലായിരിക്കാവുന്ന നാല് കാര്യങ്ങൾ വേണം: സ്വകാര്യ നാമത്തിനുള്ള DNS ഉത്തരം, ആ വിലാസത്തിലേക്കുള്ള റൂട്ട്, കേൾക്കുന്ന സേവനത്തിലെത്താനുള്ള അനുമതി, ആ സേവനം അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റിലുള്ള വിശ്വാസം. പ്രോക്സി ഹോസ്റ്റിന് ടണലിലൂടെ നാലും ഉണ്ട്. അവയൊന്നും ആ ടണലിൽ ഒരിക്കലും ഉണ്ടായിരുന്നിട്ടില്ലാത്ത ക്ലയന്റിലേക്ക് കടക്കുന്നില്ല, കാരണം ടണൽ ഹോസ്റ്റിന്റെ സ്വത്താണ്, URL-ന്റേതല്ല.

ഈ വിടവാണ് മിക്കവാറും-പ്രവർത്തിക്കുന്നു എന്ന ലക്ഷണം വിശദീകരിക്കുന്നത്. ആദ്യ അഭ്യർത്ഥന വിജയിക്കുന്നു, വിലാസ ബാർ മാറുന്നു, പിന്നീട് പ്രോക്സി എപ്പോഴും ആരോഗ്യത്തോടെയിരിക്കെ കണക്ഷൻ തൂങ്ങുകയോ പരാജയപ്പെടുകയോ ചെയ്യുന്നു. പ്രോക്സി കോൺഫിഗറേഷനിൽ ഒന്നും തകർന്നിട്ടില്ല, അത് ക്രമീകരിക്കുന്നത് 10.40.0.20-ലേക്ക് പാതയില്ലാത്ത ക്ലയന്റിനെ സഹായിക്കുന്നില്ല. ഒന്നുകിൽ ക്ലയന്റിന് റൂട്ട് ലഭിക്കുന്നു, അല്ലെങ്കിൽ പ്രോക്സി അതിനുവേണ്ടി കണക്ഷൻ ഉണ്ടാക്കണം.

പ്രോക്സിക്ക് മാത്രം ആപ്പിലെത്താനാകുമ്പോൾ

റീഡയറക്ട് പ്രവർത്തി നീക്കി, ആ അഭ്യർത്ഥനകൾ സ്വകാര്യ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന backend-ലേക്ക് അയക്കുക. frontend അതിന്റെ പൊതു നാമം നിലനിർത്തുന്നു, അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ എവിടെ പോകുന്നു എന്ന് backend തീരുമാനിക്കുന്നു. ക്ലയന്റിന്റെ പാതയിൽ ഒന്നും മാറുന്നില്ല, കാരണം പ്രോക്സി ലക്ഷ്യം വിവരിക്കുന്നത് നിർത്തി സ്വയം ലക്ഷ്യമാകുന്നു. ആന്തരിക പോർട്ട് 8080-ൽ ബോധപൂർവം കേൾക്കുന്ന ആപ്പിന് സെർവർ ബ്ലോക്ക് ചെറുതാണ്:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

ആ ബ്ലോക്കിനെ പ്രോക്സിയുടെ റൂട്ടിംഗ് പട്ടികയെക്കുറിച്ചുള്ള പ്രസ്താവനയായി വായിക്കുക: 10.40.0.20 പ്രോക്സി ഹോസ്റ്റിൽ നിന്നുതന്നെ എത്താവുന്നതായിരിക്കണം, ഇവിടെ അത് സ്ഥിര റൂട്ടിലൂടെയല്ല, VPN ഇന്റർഫേസിലൂടെയാണ്. check എന്ന കീവേഡ് ആ റൂട്ട് എന്ത് ചെയ്യുന്നു എന്ന് മാത്രം അറിയിക്കുന്നു, ആരോഗ്യ പാത ആപ്പിൽ ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ ഓരോ പരിശോധനയും സെർവറിനെ ഡൗൺ എന്ന് അടയാളപ്പെടുത്തും. വിജയിച്ച പരിശോധന ക്ലയന്റിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, ആര് backend ഉപയോഗിക്കാമെന്ന് തീരുമാനിക്കുന്ന നയത്തെ മാറ്റിസ്ഥാപിക്കുന്നുമില്ല.

ഈ ഭാഗം പൂർണ്ണമായ frontend അല്ല. ലിസണർ, പ്രാമാണീകരണം, അനുവദിച്ച ഹോസ്റ്റും പാതയും തിരഞ്ഞെടുക്കൽ, ആപ്പിൽ ആര് എത്താം എന്ന് തീരുമാനിക്കുന്ന നിയമം എന്നിവ നിലനിർത്തുക. backend പ്രോട്ടോക്കോളും ഒപ്പമാക്കുക, കാരണം HTTPS backend-ന് സർട്ടിഫിക്കറ്റ് പരിശോധനയും സെർവർ ഐഡന്റിറ്റി കോൺഫിഗറേഷനും വേണം, ആ പരിശോധന ഒഴിവാക്കുന്നത് സ്വകാര്യ കണക്ഷനെ പരിശോധിക്കാത്തതാക്കി മാറ്റുന്നു.

വിജയം പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് ഇരു ദിശകളിലും തിരിച്ചുവരവ് പാത സ്ഥിരീകരിക്കുക. ആപ്പ് ഇപ്പോൾ പ്രോക്സിയിൽ നിന്നുള്ള കണക്ഷൻ കാണുന്നു, അതിനാൽ അതിന്റെ ലോഗുകളും ഏതെങ്കിലും ക്ലയന്റ് വിലാസ മെറ്റാഡാറ്റയും പ്രോക്സിയെ വിവരിക്കുന്നു, മറിച്ച് ക്രമീകരിച്ചില്ലെങ്കിൽ. ഐഡന്റിറ്റിയും ഫോർവേഡ് ചെയ്ത വിലാസങ്ങളും എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്ന് തീരുമാനിക്കുക, അനുമാനിക്കുന്നതിന് പകരം തീരുമാനം പരിശോധിക്കുക.

ആപ്പിന്റെ സ്വന്തം റീഡയറക്ടുകൾ ഇപ്പോഴും ഉള്ളിലേക്ക് ചൂണ്ടുന്നു

ആദ്യ അഭ്യർത്ഥന കൈമാറുന്നത് സംയോജനത്തിന്റെ പകുതി മാത്രം. കേവല റീഡയറക്ടുകൾ, കട്ടിയായി കോഡ് ചെയ്ത അസറ്റ് URL-കൾ, അല്ലെങ്കിൽ ഉള്ളിൽ അറിയുന്ന നാമത്തിൽ പരിമിതപ്പെടുത്തിയ കുക്കികൾ എന്നിവ ആപ്പ് പുറപ്പെടുവിച്ചേക്കാം, അവയോരോന്നും ബ്രൗസറിനെ എത്താനാകാത്ത വിലാസത്തിലേക്ക് തിരികെ അയക്കുന്നു. ആന്തരിക നാമത്തിലേക്ക് ചൂണ്ടുന്ന Location ഹെഡർ യഥാർത്ഥ പ്രശ്നത്തോട് സമാനമായി കാണുന്നു, അതിനാലാണ് അത് പ്രോക്സി പരാജയമായി തെറ്റായി രോഗനിർണയം ചെയ്യുന്നത്.

ആപ്പിന്റെ രേഖപ്പെടുത്തിയ ബാഹ്യ URL-ഉം അതിന്റെ പ്രോക്സി ഓപ്ഷനുകളും സജ്ജമാക്കുക, പിന്നീട് Host ഹെഡർ വെർച്വൽ ഹോസ്റ്റുമായും സർട്ടിഫിക്കറ്റ് പ്രതീക്ഷകളുമായും ഒത്തുപോകുന്നതാക്കുക. ആന്തരിക നാമത്തിൽ പരിമിതപ്പെടുത്തിയ കുക്കി പൊതു നാമത്തിലൂടെ തിരികെ വരില്ല, തുടർന്നുള്ള സൈൻ-ഇൻ ലൂപ്പ് പ്രാമാണീകരണ ബഗ്ഗായി വായിക്കപ്പെടുന്നു. ആദ്യം ബാഹ്യ URL മാറ്റുക, ശുദ്ധമായ ബ്രൗസർ പ്രൊഫൈലിൽ നിന്ന് വീണ്ടും പരിശോധിക്കുക, പകുതി കുടിയേറിയ ക്രമീകരണങ്ങൾ വിജയിക്കുന്ന ലോഗിനും ഉടൻ മരിക്കുന്ന സെഷനും നൽകുമെന്ന് പ്രതീക്ഷിക്കുക.

ഫോർവേഡ് ചെയ്ത മെറ്റാഡാറ്റയെ നിർദ്ദിഷ്ട പ്രോക്സിയിൽ നിന്ന് മാത്രം വിശ്വസിക്കുക. ഏത് ക്ലയന്റിനും സജ്ജമാക്കാവുന്ന ഹെഡർ ഒരിക്കലും അധികാര മൂല്യമാകരുത്, അല്ലെങ്കിൽ പ്രോക്സി വിളിക്കുന്നയാൾ മറ്റൊരാളുടെ ഐഡന്റിറ്റി അവകാശപ്പെടാനുള്ള വഴിയാകുന്നു. ആ നിയമം റീഡയറക്ട് ചോദ്യത്തിൽ നിന്ന് സ്വതന്ത്രമാണ്, തുടർന്നുള്ള ഏത് പുനർരൂപകൽപ്പനയെയും അതിജീവിക്കുന്നു.

യഥാർത്ഥത്തിൽ ഏത് രൂപകൽപ്പനയാണ് നിങ്ങൾക്കുള്ളതെന്ന് തീരുമാനിക്കുക

ഓരോ ഉപയോക്താവിനും ഇതിനകം അധികാരമുള്ള VPN ആക്സസ് ഉണ്ടെങ്കിൽ, സ്വകാര്യ URL-ലേക്കുള്ള റീഡയറക്ട് ബോധപൂർവമായ രൂപകൽപ്പനയാകാം. ആ ആവശ്യകത അനുമാനിക്കാതെ വ്യക്തമായി സ്ഥിരീകരിക്കുക, കാരണം രണ്ട് രൂപകൽപ്പനകളും തികച്ചും വ്യത്യസ്ത ജനസംഖ്യകളെ സേവിക്കുന്നു. അവയിലൊന്ന് ഹോട്ടൽ നെറ്റ്വർക്കിൽ നിന്ന് ഒട്ടും പ്രവർത്തിക്കുന്നില്ല, മറ്റൊന്ന് പൊതു URL ലോഡ് ചെയ്യാവുന്ന ആർക്കും ആപ്പ് തുറന്നുകാട്ടുന്നു. ആ വ്യത്യാസം രൂപകൽപ്പന കുറിപ്പിൽ ഉണ്ടായിരിക്കണം.

ഉപയോക്താക്കളുടെ നെറ്റ്വർക്കിലെ ഒരു മെഷീനിൽ നിന്ന് പരിശോധന നടത്തി ബ്രൗസർ ചെയ്യുന്ന ഓരോ ഹോപ്പും പിന്തുടരുക, ആദ്യ പ്രതികരണം മാത്രമല്ല. വിലാസ ബാറും തുടർന്നുള്ള ഓരോ അഭ്യർത്ഥനയും നിരീക്ഷിക്കുക, കാരണം അസറ്റ് ടാഗിലെ ഒരു കേവല URL ആദ്യ ഹോപ്പ് കടന്ന ഒഴുക്ക് തകർക്കാൻ മതി. സൈൻ-ഇൻ പൊതു നാമത്തിലൂടെ പ്രവർത്തിക്കണം, നിഷേധിക്കേണ്ട വിഭവങ്ങൾ നിഷേധിക്കപ്പെട്ടുതന്നെ ഇരിക്കണം.

ഒരു റിവേഴ്സ് പ്രോക്സി പ്രസിദ്ധീകരിക്കുന്നത് വേറിട്ട ആക്സസ് തീരുമാനമാണ്, പ്രോക്സിയുടെ സ്വന്തം VPN പൊതു URL ലോഡ് ചെയ്യാവുന്ന എല്ലാവർക്കുമായി സുതാര്യമായി വ്യാപിപ്പിക്കലല്ല. ഡയഗ്രാമിൽ രണ്ടും സമാനമായി കാണുന്നു, ആരെ അകത്തേക്ക് അനുവദിക്കുന്നു എന്നതിൽ വ്യത്യാസപ്പെടുന്നു. ആ ചോദ്യം വിന്യാസത്തിന് ശേഷം തീരുമാനിക്കുന്നതാണ് ഒരു ആന്തരിക ആപ്പ് ആകസ്മികമായി പൊതുവായതാകുന്ന വഴി.

രണ്ടിൽ ഏതാണ് നിർമ്മിച്ചതെന്നും എന്തുകൊണ്ടെന്നും എഴുതിവയ്ക്കുക. കോൺഫിഗറേഷൻ തൊടുന്ന അടുത്ത വ്യക്തി മറ്റൊന്ന് അനുമാനിക്കും. സൗകര്യത്തിനായി ചേർത്ത ഒരു റീഡയറക്ട് മാത്രം യഥാർത്ഥ പരാജയം വീണ്ടും സൃഷ്ടിക്കാൻ മതി, ലക്ഷണം നിങ്ങൾ ഇപ്പോൾ ശരിയാക്കിയതിനോട് കൃത്യമായി സമാനമായി കാണും.

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