VPN കണ്ടെയ്നറിനുള്ളിലെ വെബ് ഇന്റർഫേസ് ലക്ഷ്യമാക്കി: പോർട്ടിന്റെ ഉടമയെ തിരഞ്ഞെടുക്കുക

ആപ്പിൽ ഒന്നും തെറ്റില്ല, ടണലിൽ ഒന്നും തെറ്റില്ല, എന്നിട്ടും ഡാഷ്ബോർഡ് ലോഡ് ചെയ്യുന്നില്ല. ഒരു സേവനം network_mode: service:vpn ഉപയോഗിച്ച് പ്രവർത്തിക്കുമ്പോൾ, അത് VPN കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസ് പങ്കിടുന്നു, അതായത് അതിന്റെ ലിസണറും പ്രസിദ്ധീകരിച്ച പോർട്ടുകളും സേവനത്തിന്റേതല്ല, ആ നെയിംസ്പേസിന്റേതാണ്. അതിൽ നിന്ന് മൂന്ന് തീരുമാനങ്ങൾ ഉണ്ടാകുന്നു: ആപ്പ് എവിടെ ബൈൻഡ് ചെയ്യുന്നു, ഏത് കണ്ടെയ്നർ പോർട്ട് പ്രസിദ്ധീകരിക്കുന്നു, മാനേജ്മെന്റ് പാത എത്ര ഇടുങ്ങിയതാണ്. അവ തെറ്റായ ക്രമത്തിൽ ചെയ്താൽ ഓരോ സെറ്റിംഗും ശരിയെന്ന് തോന്നും, പക്ഷേ സംയോജനത്തിന് പ്രവർത്തിക്കാനാവില്ല.

പോർട്ട് നെയിംസ്പേസിന്റെ ഉടമ ആര്

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

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

നെയിംസ്പേസ് പ്രതീക്ഷിക്കുന്നിടത്ത് ആപ്പിനെ കേൾപ്പിക്കുക

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

ആപ്പിനുള്ളിലെ ലിസണർ പട്ടിക ബൈൻഡ് വിലാസത്തെക്കുറിച്ച് സത്യം പറയുന്നു, docker port ഉടമ യഥാർത്ഥത്തിൽ എന്ത് പ്രസിദ്ധീകരിച്ചു എന്ന് പറയുന്നു. ആദ്യത്തേത് 127.0.0.1 കാണിക്കുകയും രണ്ടാമത്തേത് ഹോസ്റ്റ് മാപ്പിംഗ് കാണിക്കുകയും ചെയ്താൽ, VPN കോൺഫിഗറേഷൻ തൊടാതെ തന്നെ പൊരുത്തക്കേട് കണ്ടെത്തി.

മാനേജ്മെന്റ് പാത എങ്ങനെ അകത്ത് വരണമെന്ന് തിരഞ്ഞെടുക്കുക

മൂന്ന് ന്യായമായ ക്രമീകരണങ്ങളുണ്ട്. VPN കണ്ടെയ്നറിൽ പ്രസിദ്ധീകരിച്ച് ഹോസ്റ്റിൽ നിന്നോ ലോക്കൽ നെറ്റ്വർക്കിൽ നിന്നോ എത്തുക. നെയിംസ്പേസിന് മുന്നിൽ ഒരു റിവേഴ്സ് പ്രോക്സി വയ്ക്കുക, പ്രോക്സിക്ക് ഏക തുറന്ന പോർട്ട് നൽകുക. അല്ലെങ്കിൽ ഡാഷ്ബോർഡ് നെയിംസ്പേസിനുള്ളിൽ നിന്ന് മാത്രം exec സെഷൻ അല്ലെങ്കിൽ SSH ടണൽ വഴി എത്താവുന്നതാക്കി വയ്ക്കുക, ഇത് ഏറ്റവും കുറഞ്ഞ വെളിപ്പെടുത്തലും ഏറ്റവും കുറഞ്ഞ സൗകര്യവുമാണ്.

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

എല്ലാം തുറക്കാതെ മാനേജ്മെന്റ് പോർട്ട് തുറക്കുക

VPN ക്ലയന്റിന്റെ സ്വന്തം ലോക്കൽ-ആക്സസ് അല്ലെങ്കിൽ ലോക്ക്ഡൗൺ നയം, പുറത്തേക്കുള്ള ടണൽ തികച്ചും പ്രവർത്തിക്കുമ്പോഴും, അകത്തേക്കുള്ള മാനേജ്മെന്റ് അഭ്യർത്ഥന വീഴ്ത്താം. ഉദ്ദേശിച്ച ഉറവിടത്തിനും പോർട്ടിനും ഒരു രേഖപ്പെടുത്തിയ ഒഴിവിന് അനുവാദം നൽകുക, തുടർന്ന് ടണലിന്റെ സാധാരണ സംരക്ഷണം മാറിയിട്ടില്ലെന്ന് ഉറപ്പാക്കുക. ഡാഷ്ബോർഡ് ലോഡ് ചെയ്യാൻ കിൽ സ്വിച്ച് ഓഫ് ചെയ്യുന്നത് ബ്രൗസർ ടാബിന് പകരം യഥാർത്ഥ നിയന്ത്രണം നഷ്ടപ്പെടുത്തുന്നതാണ്.

ആപ്പിന്റെ സ്വന്തം പ്രാമാണീകരണം ഓണായി വയ്ക്കുക. VPN ബന്ധിപ്പിച്ച സ്റ്റാക്കിനുള്ളിൽ ആയിരിക്കുന്നത് ഓരോ ലോക്കൽ ഉപയോക്താവിനെയും ഹോസ്റ്റിൽ എത്താവുന്ന ഓരോ ഉപകരണത്തെയും അധികാരപ്പെടുത്തുന്നില്ല, ടണലിന് പിന്നിലെ പ്രാമാണീകരണമില്ലാത്ത അഡ്മിൻ പാനൽ ഇപ്പോഴും പ്രാമാണീകരണമില്ലാത്ത അഡ്മിൻ പാനലാണ്.

മാനേജ്മെന്റ് ഉപകരണത്തിൽ നിന്ന് പരിശോധിക്കുക, പിന്നീട് വീണ്ടും പരിശോധിക്കുക

സേവനം യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന മെഷീനിൽ നിന്ന് പരീക്ഷിക്കുക, ഹോസ്റ്റിൽ നിന്നല്ല, തുടർന്ന് ആപ്പിന് ആവശ്യമായ ഇന്റർനെറ്റ് പാത വെവ്വേറെ പരിശോധിക്കുക. മാനേജ്മെന്റിലെ വിജയം ഒരു ദിശ തെളിയിക്കുന്നു, പുറത്തേക്കുള്ളതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

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