ഒരു പൊതു പ്രോക്സി VPN വഴി സ്വകാര്യ ഉത്ഭവത്തിൽ എത്തുന്നത് എങ്ങനെ

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

ഒരു ഡയഗ്രാമിൽ ഒരുപോലെ തോന്നുന്ന രണ്ട് മാതൃകകൾ

എന്തെങ്കിലും തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് അമ്പുകൾ വരയ്ക്കുക. പൊതു പ്രസിദ്ധീകരണ മാതൃക ബ്രൗസറിൽ നിന്ന് പ്രോക്സിയിലേക്ക് HTTPS വഴി പോകുന്നു, തുടർന്ന് പ്രോക്സിയിൽ നിന്ന് ഉത്ഭവത്തിലേക്ക് ടണലിലൂടെ പോകുന്നു, ഉത്ഭവം ഇന്റർനെറ്റിൽ നിന്ന് ഒരിക്കലും കണക്ഷൻ സ്വീകരിക്കുന്നില്ല. VPN മാത്രം മാതൃക ക്ലയന്റിൽ നിന്ന് ഗേറ്റ്വേയിലേക്ക് പോകുന്നു, ആപ്ലിക്കേഷൻ ആ പാതയുടെ ഉള്ളിൽ നിന്ന് മാത്രം ലഭ്യമാണ്. ഉപയോക്താവിന്റെ ലാപ്ടോപ്പ് ആപ്ലിക്കേഷനുമായി ഒരേ നെറ്റ്വർക്കിലാണ്, അതാണ് ആ മാതൃകയുടെ മുഴുവൻ ഉദ്ദേശ്യം.

മാതൃകകൾ ആരാണ് പ്രാമാണീകരിക്കുന്നത്, എവിടെയാണ് എന്നതിൽ വ്യത്യസ്തമാണ്. ആദ്യത്തേതിൽ, പ്രോക്സി പൊതു പ്രവേശനമാണ്, അതിൽ കോൺഫിഗർ ചെയ്ത നയത്തിന് വിധേയമായി വരുന്ന ഏത് അഭ്യർത്ഥനയും, ശത്രുതയുള്ളതും ഉൾപ്പെടെ, കൈമാറുന്നു. രണ്ടാമത്തേതിൽ, ലഭ്യത തന്നെയാണ് കവാടം, അത് പരുക്കനാണെങ്കിലും യഥാർത്ഥ പ്രവേശനമാണ്.

TLS എവിടെ നിൽക്കുന്നു, അത് യഥാർത്ഥത്തിൽ എന്താണ് തെളിയിക്കുന്നത്

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

ഇതാണ് ആളുകൾ എൻക്രിപ്റ്റ് ചെയ്ത എന്ന വാക്കിൽ ഒതുക്കുന്ന ഭാഗം. രഹസ്യത, സമഗ്രത, സെർവർ ഐഡന്റിറ്റി എന്നിവ ഗതാഗത സവിശേഷതകളാണ്; അനുമതി ആപ്ലിക്കേഷന്റെ തീരുമാനമാണ്. ടണലിന് പിന്നിലെ സ്വകാര്യ വിലാസം ആർക്ക് സോക്കറ്റിൽ എത്താം എന്നത് മാറ്റുന്നു, എത്തിയ ശേഷം ആർക്ക് ലോഗിൻ ചെയ്യാം എന്നതല്ല.

ഫോർവേഡ് ചെയ്ത ഹെഡറുകൾ പ്രോക്സിയിൽ നിന്ന് മാത്രം വിശ്വസിക്കുക

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

ആ അഭ്യർത്ഥന പ്രോക്സിയല്ലാത്ത ഒരു ഹോസ്റ്റിൽ നിന്ന് വിജയിക്കുന്നുവെങ്കിൽ, ഉത്ഭവം അവഗണിക്കേണ്ട ഒരു ഹെഡറിൽ വിശ്വസിക്കുന്നു. ആപ്ലിക്കേഷനിൽ സ്പർശിക്കുന്നതിന് മുമ്പ് ലിസണർ ശരിയാക്കുക. വ്യാജ വിലാസം വഹിക്കുന്ന ലോഗ് വരിയെക്കാൾ വളരെ മികച്ച ഫലമാണ് നിരസിക്കൽ.

ഉത്ഭവം കൃത്യമായി ഒരു സ്ഥലത്ത് നിന്ന് മാത്രം ലഭ്യമായി നിലനിർത്തുക

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

ss -ltnp | grep -E ':(80|443)'

മാനേജ്മെന്റ് ഇന്റർഫേസുകൾക്കും അതേ അവലോകനം നടത്തുക, ആകസ്മിക വെളിപ്പെടുത്തൽ സാധാരണയായി അവിടെയാണ്. തുടർന്ന് രണ്ട് മാതൃകകളും വെവ്വേറെ എഴുതുക: പ്രോക്സിയിലൂടെയുള്ള പൊതു സൈറ്റ്, ടണലിലൂടെ മാത്രം ലഭ്യമായ അഡ്മിനിസ്ട്രേഷൻ ഇന്റർഫേസ്. സെർവർ VPN-ന് പിന്നിലാണ് എന്ന വാക്യം അവയിൽ ഒന്നും പറയുന്നില്ല.