കണ്ടെയ്നർ VPN-മാത്രം ആക്സസ് ചെയ്യാവുന്ന API-യിൽ എത്തുന്നില്ലേ? ഹോസ്റ്റിൽ പ്രോക്സി ചെയ്യുക

ഒരേ യന്ത്രത്തിലെ ബ്രൗസർ ഒരു പരാതിയുമില്ലാതെ തുറക്കുന്ന API-യോട് നിങ്ങളുടെ Compose സേവനം സമയപരിധി കവിയുന്നു. ആ വ്യത്യാസമാണ് സൂചന: പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥന VPN ടണലുള്ള ഹോസ്റ്റിൽ നിന്ന് പുറപ്പെടുന്നു, തൂങ്ങിക്കിടക്കുന്ന അഭ്യർത്ഥന സ്വന്തം നെറ്റ്വർക്ക് സ്റ്റാക്കുള്ള കണ്ടെയ്നറിൽ നിന്ന് പുറപ്പെടുന്നു. കണ്ടെയ്നറിനുള്ളിൽ ഒന്നിനും ടണലിന്റെ റൂട്ടുകൾ അറിയില്ല, അതിനാൽ പേര് എങ്ങനെ എഴുതിയാലും സ്വകാര്യ ലക്ഷ്യം എത്താനാവാത്തതായി തുടരും. പരിഹാരം ഹോസ്റ്റിലൂടെയുള്ള ബോധപൂർവമായ ഒരു ചാട്ടമാണ്, കൂടുതൽ മിടുക്കിയായ റൂട്ടിംഗ് പട്ടികയല്ല.

രണ്ട് പാതകൾ എന്തുകൊണ്ട് വ്യത്യസ്തമാണ് എന്നതിൽ തുടങ്ങി, ടണൽ എവിടെ ജീവിക്കണം എന്ന് തീരുമാനിക്കുക.

ഹോസ്റ്റ് എന്തുകൊണ്ട് പ്രവർത്തിക്കുന്നു, കണ്ടെയ്നർ എന്തുകൊണ്ട് ഇല്ല

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

അതുകൊണ്ടാണ് ലക്ഷണങ്ങൾ വെറുതെ തകർന്നതല്ല, പൊരുത്തക്കേടുള്ളതായി തോന്നുന്നത്. ഹോസ്റ്റ് സ്വകാര്യ പേര് പരിഹരിച്ച് ബന്ധിപ്പിക്കുന്നു, കാരണം പേരും റൂട്ടും അവിടെ ഉണ്ട്. കണ്ടെയ്നർ ബ്രിഡ്ജ് പാതയിൽ ഒന്നിനും എത്താനാവാത്ത സ്വകാര്യ വിലാസത്തിലേക്ക് പാക്കറ്റ് അയക്കുന്നു, അഭ്യർത്ഥന സമയപരിധി കവിയുന്നു. കണ്ടെയ്നറിന്റെ hosts ഫയലിൽ പേര് ചേർക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല, കാരണം വിലാസം തന്നെ കണ്ടെയ്നർ ഇരിക്കുന്നിടത്ത് നിന്ന് എത്താനാവാത്തതാണ്.

കണ്ടെയ്നറിനുള്ളിൽ നിന്ന് ഹോസ്റ്റിൽ എത്തുക

കണ്ടെയ്നറിലെ ഒരു പ്രോസസ് localhost ഡയൽ ചെയ്യുന്നുവെങ്കിൽ അത് കണ്ടെയ്നറിനെത്തന്നെ ഡയൽ ചെയ്യുന്നു. Docker Desktop host.docker.internal എന്ന പേര് എൻജിൻ പ്രവർത്തിപ്പിക്കുന്ന യന്ത്രത്തിലേക്ക് തിരികെ ചൂണ്ടുന്നതായി പ്രസിദ്ധീകരിക്കുന്നു; സേവനം ആവശ്യപ്പെട്ടില്ലെങ്കിൽ Linux എൻജിനുകൾ അത് നിർവചിക്കാതെ വിടുന്നു, താഴെയുള്ള മാപ്പിംഗ് അതാണ് ചെയ്യുന്നത്. അതോടെ ആപ്ലിക്കേഷൻ സ്വകാര്യ വിലാസത്തിനുപകരം ഒരു പേരിനെയും പോർട്ടിനെയും ലക്ഷ്യമിടുന്നു.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

ടണൽ ചാട്ടത്തിന്റെ ഹോസ്റ്റ് വശത്ത് തന്നെ തുടരുന്നു, ആ വേരിയബിളിലെ പോർട്ടാണ് പ്രോക്സി കേൾക്കാൻ പോകുന്നത്. ടണൽ നഷ്ടപ്പെടുന്ന കണ്ടെയ്നർ ഇപ്പോൾ ഒരിക്കലും ഇല്ലാതിരുന്ന ഒരു റൂട്ട് പരീക്ഷിക്കുന്നതിനുപകരം ഒരു അറിയപ്പെടുന്ന ചാട്ടത്തിൽ പരാജയപ്പെടുന്നു.

ടണൽ എവിടെ ജീവിക്കുന്നു എന്ന് തിരഞ്ഞെടുക്കുക

സ്വകാര്യ API ആവശ്യമുള്ള Compose സേവനത്തിന് മൂന്ന് രൂപങ്ങൾ സാധ്യമാണ്, അവ ഏത് പ്രോസസ് ടണൽ സ്വന്തമാക്കുന്നു എന്നതിൽ വ്യത്യസ്തമാണ്. VPN ക്ലയന്റിന് കണ്ടെയ്നർ ഇമേജിനുള്ളിൽ പ്രവർത്തിക്കാം, അതിന് ടണൽ ഉപകരണം വെളിപ്പെടുത്തുകയും അതിനൊപ്പം വരുന്ന നെറ്റ്വർക്ക് അഡ്മിനിസ്ട്രേഷൻ കഴിവ് നൽകുകയും വേണം. ആപ്ലിക്കേഷന് വേറിട്ട ടണൽ കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് നാമസ്ഥലം പങ്കിടാം, അപ്പോൾ രണ്ട് പ്രോസസുകളും ഒരു സ്റ്റാക്കും ഒരു റൂട്ടിംഗ് പട്ടികയും കാണുന്നു. അല്ലെങ്കിൽ ടണൽ ഹോസ്റ്റിൽ തുടരാം, ഹോസ്റ്റിൽ നിന്ന് കണ്ടെയ്നറിലേക്ക് ഒരു ഇടുങ്ങിയ ഫോർവേഡറോടെ.

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

ഹോസ്റ്റിൽ ഒരു ഇടുങ്ങിയ പാത മാത്രം പ്രസിദ്ധീകരിക്കുക

ഫോർവേഡർ പാരമ്പര്യമായി നേടുന്നതിൽ നിന്ന് തുടങ്ങുക: ടണൽ സ്വന്തമാക്കുന്ന അക്കൗണ്ടിൽ അത് പ്രവർത്തിപ്പിക്കുക, അപ്പോൾ അതിന്റെ പുറത്തേക്കുള്ള സോക്കറ്റുകൾ ഹോസ്റ്റിന്റെ റൂട്ടുകളും ഹോസ്റ്റിന്റെ റിസോൾവറും ഏറ്റെടുക്കും. nginx-ന്റെ ഒരു location ബ്ലോക്ക് ഒരു പാത മൂടുന്നു.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

വിലാസത്തെയും പോർട്ടിനെയും താൽക്കാലികമായി കാണുകയും API യഥാർത്ഥത്തിൽ കേൾക്കുന്ന ജോടി ഇടുകയും ചെയ്യുക. ഓരോ അധിക upstream-നും സ്വന്തം location ബ്ലോക്ക് അർഹതയുണ്ട്, ഓരോ ബ്ലോക്കും ഈ സേവനം വിളിക്കുന്ന പാതകൾ മാത്രം അനുവദിക്കണം, അല്ലെങ്കിൽ പ്രോക്സി സ്വകാര്യ നെറ്റ്വർക്കിലേക്കുള്ള പൊതുവായ വാതിലാകും. host-gateway വഴി വരുന്ന ക്ലയന്റുകൾക്ക് ശ്രോതാവിനെ ബ്രിഡ്ജ് വിലാസത്തിലേക്കും, ക്ലയന്റ് ഹോസ്റ്റിന്റെ നെറ്റ്വർക്ക് നാമസ്ഥലം പങ്കിടുമ്പോൾ മാത്രം loopback-ലേക്കും ബന്ധിക്കുക, ഒരിക്കലും 0.0.0.0-ലേക്ക് ബന്ധിക്കരുത്. ഇപ്പോഴും സ്വതന്ത്രമായ ഒരു പോർട്ടും തിരഞ്ഞെടുക്കുക: മുൻകൂട്ടി എടുത്ത നമ്പർ പ്രോക്സിയെ കേൾക്കാതെ വിടുന്നു, കണ്ടെയ്നർ സമയപരിധി കവിയുന്നത് തുടരും, ഇത് നിങ്ങൾ തുടങ്ങിയ നെറ്റ്വർക്ക് തകരാറിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല.

പോർട്ടുകൾ, പേരുകൾ, TLS തീരുമാനം

പേര് പരിഹരിക്കൽ റൂട്ടിംഗ് പോലെ തന്നെ പിരിയുന്നു. കണ്ടെയ്നറിന്റെ പൊതു തിരച്ചിലുകൾ എൻജിന്റെ റിസോൾവറിലൂടെ പോകുന്നു, അതിനാൽ ഹോസ്റ്റിൽ പരിഹരിക്കുന്ന സ്വകാര്യ പേര് കണ്ടെയ്നറിനുള്ളിൽ പരിഹരിക്കില്ല. പ്രോക്സിയാണ് സ്വകാര്യ പേര് പരിഹരിക്കുന്ന ഘടകം, കാരണം അത് ഹോസ്റ്റിന്റെ റിസോൾവർ പാരമ്പര്യമായി നേടുന്നു.

TLS എന്നത് മാറ്റിവെക്കപ്പെടുകയും പിന്നീട് അടുത്ത പരാജയം വിശദീകരിക്കുകയും ചെയ്യുന്ന തീരുമാനമാണ്. പ്രോക്സി ബൈറ്റുകൾ തൊടാതെ കൈമാറുന്നുവെങ്കിൽ, കണ്ടെയ്നർ API-യുടെ സ്വന്തം സർട്ടിഫിക്കറ്റ് കാണുന്നു, അതിന്റെ ട്രസ്റ്റ് സ്റ്റോറിൽ ആന്തരിക CA ആവശ്യമാണ്. പ്രോക്സി TLS അവസാനിപ്പിക്കുന്നുവെങ്കിൽ, ആ വിശ്വാസം ഹോസ്റ്റിലേക്ക് മാറുന്നു, ആപ്ലിക്കേഷൻ ലഭിക്കുന്ന host ഹെഡറിൽ നിന്ന് ലിങ്കുകൾ നിർമ്മിക്കാൻ തുടങ്ങുന്നു. ഒരു ക്രമീകരണം തിരഞ്ഞെടുത്ത് അത് ഓരോ റിസോഴ്സിലും പ്രയോഗിക്കുക, കാരണം മറ്റേത് നൽകുന്ന റീഡയറക്ട് കണ്ടെയ്നറിന് പരിഹരിക്കാനാവാത്ത ഹോസ്റ്റ്നാമിലേക്ക് ചൂണ്ടുന്നു.

സേവനത്തിനുള്ളിൽ നിന്ന് പരിശോധിക്കുക

അഭ്യർത്ഥന ഹോസ്റ്റിൽ നിന്നല്ല, കണ്ടെയ്നറിൽ നിന്ന് അയക്കുക: പ്രോക്സി പാതയിലേക്ക് ഒരു സാധാരണ curl, പിന്നെ ആപ്ലിക്കേഷന്റെ സ്വന്തം ആരോഗ്യ പരിശോധന. പ്രോക്സി ഉത്തരം നൽകിയിട്ടും ആപ്ലിക്കേഷൻ പരാജയപ്പെടുന്നുവെങ്കിൽ, മൂന്ന് കാര്യങ്ങൾ താരതമ്യം ചെയ്യുക: അത് നിർമ്മിക്കുന്ന അടിസ്ഥാന URL, അതിന്റെ പരിസ്ഥിതിയിലെ ഏതെങ്കിലും പ്രോക്സി വേരിയബിൾ, അത് വിശ്വസിക്കുന്ന CA. എല്ലാം കണ്ടെയ്നറിന്റെ പരിസ്ഥിതിയിലും ലോഗുകളിലും ഉണ്ട്, അവയിലൊന്ന് ശരിയാക്കുന്നത് VPN-നെ അസ്പൃശ്യമായി വിടുന്നു.

തിരഞ്ഞെടുത്ത ക്രമീകരണം പുതുതായിരിക്കുമ്പോൾ തന്നെ പ്രോജക്ടിന്റെ README-യിൽ എഴുതുക. അല്ലെങ്കിൽ ഈ സമയപരിധിയിൽ ഇടപെടുന്ന അടുത്ത വ്യക്തി ടണൽ ഹോസ്റ്റിൽ ജീവിക്കുന്നു എന്ന് വീണ്ടും കണ്ടെത്തുന്നതിൽ അതേ ഉച്ചയ്ക്ക് ശേഷം ചെലവഴിക്കും.