Dev Container VPN-ൽ മാത്രം ലഭ്യമായ ഹോസ്റ്റിൽ എത്തുന്നില്ല: എവിടെ നോക്കണം

ബ്രൗസറിനും കണ്ടെയ്നറിനും വ്യത്യസ്ത resolver, proxy, റൂട്ട് സന്ദർഭങ്ങളുണ്ട്. ഏതെങ്കിലും VPN ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന പ്രോസസ് ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് കണ്ടെത്തുക.

സ്വകാര്യ API ഡെസ്ക്ടോപ്പ് ബ്രൗസറിൽ തുറക്കുന്നു, എന്നാൽ ഡെവലപ്മെന്റ് കണ്ടെയ്നറിൽ പരാജയപ്പെടുന്നു. ഇത് വൈരുദ്ധ്യമല്ല, VPN തന്നെയാണ് കാരണമാകുന്നത് അപൂർവ്വമാണ്. ബ്രൗസറിന്റെ അഭ്യർത്ഥനയും പരാജയപ്പെട്ട അഭ്യർത്ഥനയും വ്യത്യസ്ത പ്രോസസുകൾ നടത്തിയതാണ്, വ്യത്യസ്ത resolver, proxy, റൂട്ടുകളോടെ, പലപ്പോഴും തികച്ചും വ്യത്യസ്ത നെറ്റ്വർക്ക് നാമസ്ഥലങ്ങളിൽ നിന്ന്. “എന്റെ ലാപ്ടോപ്പിൽ” എന്നത് Windows ഹോസ്റ്റ്, ഒരു WSL വിതരണം, Docker Desktop വെർച്വൽ മെഷീൻ, ആ VM-നുള്ളിലെ ഒരു കണ്ടെയ്നർ എന്നിവയെ സൂചിപ്പിക്കാം — ഒരേ ഹോസ്റ്റ്നെയ്മിന് ഓരോന്നും വ്യത്യസ്ത മറുപടി നൽകാവുന്ന നാല് സന്ദർഭങ്ങൾ. ഒരു ക്രമീകരണവും തൊടുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന പ്രോസസ് ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് കണ്ടെത്തുക.

ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് പ്രോസസ് കണ്ടെത്തുക

VPN ക്ലയന്റിൽ നിന്നല്ല, കണ്ടെയ്നർ എഞ്ചിനിൽ നിന്ന് തുടങ്ങുക. കമാൻഡ് ലൈൻ ഏത് സന്ദർഭത്തോടാണ് സംസാരിക്കുന്നതെന്നും ആ എഞ്ചിൻ ഏത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്നുവെന്നും ചോദിക്കുക, കാരണം ഡെസ്ക്ടോപ്പ് VM നിയന്ത്രിക്കുന്ന Linux കണ്ടെയ്നർ പ്രാദേശിക ഡീമൺ നിയന്ത്രിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത പാതയിലൂടെ പോകുന്നു:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows-ൽ, wsl -l -v വിതരണം WSL 2-ന് കീഴിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പറയുന്നു, അത് അതിനെ സ്വന്തം വെർച്വൽ സ്വിച്ചിന് പിന്നിലാക്കുന്നു. ആ വിശദാംശമാണ് കണ്ടെയ്നർ ഹോസ്റ്റിന്റെ റൗട്ടിംഗ് ടേബിൾ പങ്കിടുന്നുണ്ടോ അതോ ഹോസ്റ്റിൽ എത്താൻ ഫോർവേഡ് ചെയ്ത പോർട്ടോ ഹോസ്റ്റ്നെയ്മോ ആവശ്യമുള്ള NAT-ന് പിന്നിലാണോ എന്ന് തീരുമാനിക്കുന്നത്.

ഒരു അഭ്യർത്ഥന സ്ഥിരമായി സൂക്ഷിച്ച് താരതമ്യം ചെയ്യുക

സ്വകാര്യ ഹോസ്റ്റിൽ ഒരു നിരുപദ്രവകരമായ എൻഡ്പോയിന്റ് തിരഞ്ഞെടുത്ത് ഓരോ താരതമ്യത്തിനും അത് ഉപയോഗിക്കുക: ബ്രൗസറിൽ നിന്ന്, ഹോസ്റ്റ് ടെർമിനലിൽ നിന്ന്, WSL വിതരണത്തിൽ നിന്ന്, കണ്ടെയ്നറിനുള്ളിൽ നിന്ന്. ഓരോ ശ്രമത്തിനും നാല് കാര്യങ്ങൾ രേഖപ്പെടുത്തുക: പരിഹരിച്ച വിലാസം, proxy ഉപയോഗിച്ചോ, പരാജയത്തിന്റെ വർഗ്ഗം, കഴിഞ്ഞ സമയം. നെയിം ലുക്കപ്പ്, കണക്ഷൻ സ്ഥാപിക്കൽ, TLS സാധുത, HTTP നില എന്നിവ നാല് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്, അവയെ “പ്രവർത്തിക്കുന്നില്ല” എന്ന് കൂട്ടിക്കലർത്തുന്നത് ഒരു പ്രഭാതം നഷ്ടപ്പെടുത്തും.

താരതമ്യം പരാജയപ്പെടുന്ന കണ്ടെയ്നറിനുള്ളിൽ, ടൈമൗട്ടോടെ നടത്തുക, നിശ്ശബ്ദമായ ഫയർവാൾ ടെർമിനൽ മിനിറ്റുകളോളം പിടിച്ചുവയ്ക്കാതിരിക്കാൻ. പുതിയ കണ്ടെയ്നർ എഞ്ചിന്റെ നെറ്റ്വർക്ക് സന്ദർഭം പുനർനിർമ്മിക്കുന്നു, പക്ഷേ ആപ്ലിക്കേഷൻ കണ്ടെയ്നറിന്റെ നാമസ്ഥലം, proxy വേരിയബിളുകൾ, resolver എന്നിവയല്ല, അതിനാൽ യഥാർത്ഥ കണ്ടെയ്നറിലേക്ക് docker exec ചെയ്യുന്നതാണ് അധികാരമുള്ള പരിശോധന, സൈഡ്കാർ വ്യത്യാസം എഞ്ചിനിലാണോ കണ്ടെയ്നറിലാണോ എന്ന് വേർതിരിക്കാനുള്ള മാർഗ്ഗം മാത്രം:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine അടിസ്ഥാന ഇമേജിൽ busybox ഉണ്ട്, curl ഇല്ല, അത്തരം വിശദാംശമാണ് പകർത്തിയ ഡയഗ്നോസ്റ്റിക് ബ്ലോക്കിനെ പരാജയപ്പെടുത്തുന്നത്: ക്ലയന്റുള്ള ഇമേജ് തിരഞ്ഞെടുക്കുക, അല്ലെങ്കിൽ അതേ റണ്ണിൽ ചേർക്കുക. ബന്ധമില്ലാത്ത പൊതു സൈറ്റുകളുമായുള്ള താരതമ്യം ഒന്നും വേർതിരിക്കുന്നില്ല. കണ്ടെയ്നറിൽ നിന്ന് https://example.com പ്രവർത്തിക്കുന്നുവെങ്കിൽ, കണ്ടെയ്നറിന് ഇന്റർനെറ്റ് ആക്സസ് ഉണ്ടെന്ന് മാത്രമേ അറിഞ്ഞുള്ളൂ, ടണലിലൂടെ സ്വകാര്യ വിലാസത്തിൽ എത്തുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നുമില്ല. അതുപോലെ, പുതിയ ടെർമിനൽ തുറക്കുന്നത് പുതിയ ടെർമിനൽ പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു, പരാജയപ്പെട്ട ആപ്ലിക്കേഷനുമായി ഒരേ റൺടൈം പങ്കിടുന്നു എന്നല്ല.

Docker Desktop-ന് VPN-സഹിതം പ്രവർത്തിക്കാം

Docker-ന്റെ സ്വന്തം VPN-ഉം ഹോസ്റ്റ് കണക്ടിവിറ്റിയും സംബന്ധിച്ച ഡോക്യുമെന്റേഷൻ ഇതിനെ പിന്തുണയ്ക്കുന്ന ക്രമീകരണമായി വിവരിക്കുന്നു, സത്യസന്ധമായ സാരാംശം ഇത് സ്വയമേവ തകരുന്നതല്ല, പ്രവർത്തിക്കുന്നു എന്നതാണ്. ഡെസ്ക്ടോപ്പ് VM ഡിസൈൻ പ്രകാരം ഹോസ്റ്റിന്റെ ടണൽ ഒഴിവാക്കുന്നു എന്ന് കരുതരുത്; പല ക്രമീകരണങ്ങളിലും ട്രാഫിക് ഹോസ്റ്റിന്റെ ടണലിനെ ശരിയായി പിന്തുടരുന്നു, അതുകൊണ്ടാണ് “Docker VPN അവഗണിക്കുന്നു” എന്ന ഐതിഹ്യം ആത്മവിശ്വാസമുള്ളതും തെറ്റായതുമായ ഉപദേശം നൽകുന്നത്.

ഇപ്പോഴും പ്രധാനമായത് ഉപയോഗിക്കുന്ന backend, ക്ലയന്റിന്റെ split-tunnel നയം, VM-ന് ലഭിച്ച resolver കോൺഫിഗറേഷൻ എന്നിവയാണ്. റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന പക്ഷേ DNS ഇല്ലാത്ത VPN ക്ലയന്റ്, അല്ലെങ്കിൽ VM-ന് എത്താനാകാത്ത DNS സർവറിലേക്ക് തള്ളുന്ന ക്ലയന്റ്, കണ്ടെയ്നറിനുള്ളിൽ നെയിം ലുക്കപ്പ് പരാജയം സൃഷ്ടിക്കുന്നു, അതേസമയം ഹോസ്റ്റ് പ്രവർത്തിക്കുന്നു കാരണം അതിന് അധിക resolver അല്ലെങ്കിൽ കാഷെ ചെയ്ത മറുപടി ഉണ്ട്. ഇത് കണ്ടെയ്നർ വേഷത്തിലുള്ള resolver പ്രശ്നമാണ്. നിങ്ങൾ ശ്രമിക്കുന്ന ഓരോ VPN വീണ്ടും-കണക്ഷനെയും ഇത് അതിജീവിക്കുന്നു, കാരണം ടണൽ ഇതിനകം നിങ്ങൾ ആവശ്യപ്പെട്ട ട്രാഫിക് വഹിക്കുന്നു.

വിലാസ ഓവർലാപ്പും MTU-വും വ്യത്യസ്ത പരാജയങ്ങളാണ്

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

രണ്ടാമത്തേത് MTU പ്രശ്നമാണ്. കണക്ഷൻ സ്ഥാപിക്കപ്പെടുകയും TLS പൂർത്തിയാകുകയും ചെയ്തിട്ടും വലിയ മറുപടികൾ കുടുങ്ങുകയാണെങ്കിൽ, അത് പാക്കറ്റ് വലിപ്പ പ്രശ്നമാണ്, അനുമതിയുടേതല്ല, DNS റെക്കോർഡുകൾ മാറ്റുന്നത് അത് ഒരിക്കലും ശരിയാക്കില്ല. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ചെറിയതും വലിയതുമായ അഭ്യർത്ഥന ഉപയോഗിച്ച് പരീക്ഷിക്കുക, രണ്ട് ഫലങ്ങളും രേഖപ്പെടുത്തുക.

ഓവർലാപ്പിന്റെ പരിഹാരം വിലാസ പ്ലാനിന്റെ ഉടമ തിരഞ്ഞെടുക്കുന്ന മറ്റൊരു കണ്ടെയ്നർ സബ്നെറ്റോ പരിമിതമായ റൂട്ടോ ആണ്. MTU കുടുക്കത്തിന്റെ പരിഹാരം ടണലിന്റെയോ ഇന്റർഫേസിന്റെയോ MTU പാതയിൽ നിലനിൽക്കുന്ന മൂല്യത്തിലേക്ക് ചുരുക്കുകയോ കുറയ്ക്കുകയോ ചെയ്യുകയാണ്, നിങ്ങൾ നിയന്ത്രിക്കുന്ന പാളിയിൽ പ്രയോഗിച്ച്.

proxy കോൺഫിഗറേഷൻ പ്രോസസ്സിന്, മെഷീനല്ല

കണ്ടെയ്നറിനുള്ളിൽ, localhost ആ കണ്ടെയ്നറിന്റെ സ്വന്തം നെറ്റ്വർക്ക് സന്ദർഭത്തെ സൂചിപ്പിക്കുന്നു, അതിനാൽ ഹോസ്റ്റിൽ പ്രവർത്തിക്കുന്ന proxy അവിടെ ആ പേരിൽ ലഭ്യമല്ല. ഹോസ്റ്റ് ആക്സസിനായി Docker Desktop host.docker.internal നൽകുന്നു, Linux-ൽ നിങ്ങൾ അത് --add-host=host.docker.internal:host-gateway ഉപയോഗിച്ച് വ്യക്തമായി ചേർക്കുന്നു. ഏതായാലും, ആ പേര് നിങ്ങൾക്ക് ഹോസ്റ്റിലേക്ക് ഒരു റൂട്ട് നൽകുന്നു; അത് proxy സേവനം സൃഷ്ടിക്കുന്നില്ല, ഉപയോഗിക്കാനുള്ള അനുമതിയും നൽകുന്നില്ല.

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

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

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