Docker കണ്ടെയ്നർ VPN-ന് പിന്നിലുള്ള ഹോസ്റ്റുകളിൽ എത്താത്തതെന്തുകൊണ്ട്

കോർപ്പറേറ്റ് VPN-ന് പിന്നിൽ ഒന്നിലും എത്താത്ത കണ്ടെയ്നർ സാധാരണയായി ടണലിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു നെറ്റ്വർക്ക് നെയിംസ്പേസിലാണ് ജീവിക്കുന്നത്. ഹോസ്റ്റ് ക്ലയന്റിന്റെ റൂട്ടുകൾ, DNS സെർവറുകൾ, ഫയർവാൾ അടയാളങ്ങൾ എന്നിവ ഹോസ്റ്റിന്റെ സ്റ്റാക്കിന്റേതാണ്; ബ്രിഡ്ജ് നെറ്റ്വർക്ക് കണ്ടെയ്നറിന് സ്വന്തം സ്റ്റാക്കുണ്ട്. ഈ ഒരു വസ്തുത പ്ലാറ്റ്ഫോം ടീമിലേക്ക് എത്തുന്ന മിക്ക റിപ്പോർട്ടുകളും വിശദീകരിക്കുന്നു, കൂടാതെ «VPN കേടായി» എന്നതും «Docker VPN-നെ ഒഴിവാക്കുന്നു» എന്നതും ഒരേ സമയം തെറ്റാകാമെന്നതിന്റെ കാരണവുമാണ്. ഒരു ലക്ഷണത്തിന് പിന്നിൽ രണ്ട് വളരെ വ്യത്യസ്ത ക്രമീകരണങ്ങൾ ഒളിഞ്ഞിരിക്കുന്നു, അതിനാൽ ഏതെങ്കിലും ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ് നിങ്ങളുടേത് ഏതാണെന്ന് തിരിച്ചറിയുക.

ടണൽ ആരുടെ നെയിംസ്പേസിലാണെന്ന് കണ്ടെത്തുക

macOS അല്ലെങ്കിൽ Windows-നുള്ള Docker Desktop-ൽ കണ്ടെയ്നറുകൾ ഒരു Linux വെർച്വൽ മെഷീനിനുള്ളിൽ പ്രവർത്തിക്കുന്നു. ഡെസ്ക്ടോപ്പിൽ ഇൻസ്റ്റാൾ ചെയ്ത VPN ക്ലയന്റ് ഡെസ്ക്ടോപ്പ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ ഒരു ടണൽ സൃഷ്ടിക്കുന്നു, വെർച്വൽ മെഷീൻ അത് ഒരിക്കലും കാണുന്നില്ല. ഏതെങ്കിലും കണ്ടെയ്നർ കോൺഫിഗറേഷൻ അത് ശരിയാക്കുന്നില്ല, കാരണം കണ്ടെയ്നറിന് ആവശ്യമായ ഇന്റർഫേസ് അതിന്റെ നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ ഒട്ടും നിലവിലില്ല.

Linux ഹോസ്റ്റിൽ ടണൽ ഹോസ്റ്റിന്റെ നെയിംസ്പേസിലാണ്, ബ്രിഡ്ജ് കണ്ടെയ്നറുകൾ സാധാരണയായി പുറത്തേക്ക് പോകുമ്പോൾ സ്രോതസ്സ് NAT പ്രയോഗിച്ച ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടികയിലൂടെ അതിൽ എത്തുന്നു. ആ വഴി പരാജയപ്പെടുമ്പോൾ, കാരണം സാധാരണയായി കാണാത്ത ഒരു റൂട്ടല്ല, മറിച്ച് ഫോർവേഡിംഗ് നയം, റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് അല്ലെങ്കിൽ ഓവർലാപ്പിംഗ് സബ്നെറ്റ് ആണ്. കൂടുതൽ വായിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ ഏത് ലോകത്താണെന്ന് സ്ഥിരീകരിക്കുക:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് ഒരു പരീക്ഷണമാണ്, രൂപകൽപ്പനയല്ല

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

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

ഇത് രോഗനിർണ്ണയമായി സൂക്ഷിക്കുക. ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് പോർട്ട് പ്രസിദ്ധീകരണവും കണ്ടെയ്നറിൽ നിന്ന് നിങ്ങൾ ആഗ്രഹിച്ച ഒറ്റപ്പെടുത്തലിന്റെ മിക്കതും ഉപേക്ഷിക്കുന്നു, Docker Desktop-ൽ «host» എന്നത് വെർച്വൽ മെഷീനാണ്, ഡെസ്ക്ടോപ്പല്ല, അതിനാൽ ഏത് ഹോസ്റ്റിനെ സംബോധന ചെയ്യുകയായിരുന്നു എന്ന് മറന്നാൽ അവിടത്തെ വിജയമോ പരാജയമോ നിങ്ങളെ തെറ്റിദ്ധരിപ്പിക്കാം.

tun ഉപകരണവും അതിനൊപ്പം വരുന്ന അനുമതികളും

കണ്ടെയ്നറിനുള്ളിലെ VPN ക്ലയന്റിന് ടണൽ ഉപകരണവും അത് കോൺഫിഗർ ചെയ്യാനുള്ള അനുമതിയും ആവശ്യമാണ്. സാധാരണ ഷോർട്ട്കട്ട് --privileged ആണ്, അത് എല്ലാ ഉപകരണവും നൽകുകയും മുഴുവൻ കണ്ടെയ്നറിലും സുരക്ഷാ നയം അയയ്ക്കുകയും ചെയ്യുന്നു. ഇത് ഈ ജോലി ആവശ്യപ്പെടുന്നതിനേക്കാൾ വളരെ കൂടുതലാണ്, അവലോകനത്തിൽ ന്യായീകരിക്കാൻ പ്രയാസമാണ്.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

ഈ രൂപകൽപ്പന അർത്ഥമാക്കുന്നത് ക്ലയന്റ് ഓരോ കണ്ടെയ്നറിനും പ്രവർത്തിക്കുന്നു എന്നാണ്. ഓരോ വർക്ക്ലോഡിനും സ്വന്തം ടണൽ വേണ്ടിവരുമ്പോൾ ഇത് ശരിയായ ഉത്തരമാണ്, ഹോസ്റ്റിന്റെ ടണൽ കാണണം എന്ന് മാത്രം ആഗ്രഹിച്ചിരുന്നെങ്കിൽ തെറ്റായ ഉത്തരവും — പ്ലാറ്റ്ഫോം ടീം നിങ്ങൾ അതാണ് ചെയ്യുന്നതെന്ന് അനുമാനിച്ചിരിക്കാം.

ബ്രിഡ്ജ് NAT VPN കാണുന്ന സ്രോതസ്സിനെ മാറ്റുന്നു

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

macvlan അല്ലെങ്കിൽ ipvlan പകരം കണ്ടെയ്നറിന് LAN വിലാസം നൽകുന്നു, അത് LAN കണ്ടെത്തലിന് സഹായിക്കുകയും കണ്ടെയ്നറിനെ സെഗ്മെന്റിൽ തുല്യനായി കാണിക്കുകയും ചെയ്യുന്നു. അത് ഹോസ്റ്റിന്റെ ടണലിനെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു, അതിനാൽ അത്തരം കണ്ടെയ്നർ VPN-മാത്ര പ്രിഫിക്സുകളിൽ എത്തില്ല, VPN ആ LAN-ൽ നിന്നും ലഭ്യമല്ലെങ്കിൽ.

രണ്ട് രൂപങ്ങളും സാധുവാണ്; അവ വ്യത്യസ്ത ആവശ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ആവശ്യം «ഈ കണ്ടെയ്നർ VPN-മാത്ര സേവനത്തിൽ എത്തണം» എന്നാണെങ്കിൽ, ഹോസ്റ്റിലൂടെയുള്ള റൂട്ടിംഗും കണ്ടെയ്നറിനുള്ളിൽ ടണൽ അവസാനിപ്പിക്കലും തമ്മിൽ തിരഞ്ഞെടുക്കുന്നു. ആ തിരഞ്ഞെടുപ്പ് വിന്യസിക്കുന്നതിന് മുമ്പ് എഴുതുക, ആദ്യ പരാജയ അഭ്യർത്ഥനയ്ക്ക് ശേഷമല്ല. എന്ത് തിരഞ്ഞെടുത്താലും, ദൂരെയുള്ള അറ്റം കാണുന്ന സ്രോതസ്സ് വിലാസം രേഖപ്പെടുത്തുക, കാരണം അതിന്റെ ആക്സസ് നിയമങ്ങളും ലോഗുകളും അതാണ് കാണിക്കുക. ആ വിലാസം പറയാൻ കഴിയാത്ത രൂപകൽപ്പന പൂർത്തിയായിട്ടില്ല.

DNS ഡീമണിനെ പിന്തുടരുന്നു, ടണലിനെയല്ല

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

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

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

ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുമ്പുള്ള ചെക്ക്‌ലിസ്റ്റ്: ടണൽ ഉള്ള നെയിംസ്പേസ് തിരിച്ചറിയുക, ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗ് ഉപയോഗിച്ച് വഴി തെളിയിക്കുക, ആവശ്യമായ tun ഉപകരണം മാത്രം മാപ്പ് ചെയ്യുക, NAT-ന് ശേഷമുള്ള സ്രോതസ്സ് വിലാസം ഓർക്കുക, റെസോൾവർ വ്യക്തമായി സജ്ജമാക്കുക, ഓരോ കണ്ടെയ്നറിന്റെയും എക്സിറ്റ് വിലാസങ്ങളെ ഫ്ലാഗല്ല, ആർക്കിടെക്ചർ തീരുമാനമായി കാണുക.