Docker കണ്ടെയ്നർ ട്രാഫിക് ഹോസ്റ്റ് VPN ഒഴിവാക്കുന്നു: എങ്ങനെ പരിശോധിക്കാം
ഹോസ്റ്റ് VPN ഹോസ്റ്റിന്റെ നെറ്റ്‌വർക്ക് നെയിംസ്‌പേസ് മാത്രമാണ് ഉൾക്കൊള്ളുന്നത്. ബ്രിഡ്ജിലുള്ള കണ്ടെയ്നർ ട്രാഫിക് ടണലിൽ പ്രവേശിക്കുന്നുണ്ടോ നേരിട്ട് പുറത്തുപോകുന്നുണ്ടോ എന്ന് ഈ പരിശോധനകളിലൂടെ അറിയാം.
ഹോസ്റ്റിലെ നിങ്ങളുടെ ബ്രൗസർ VPN എക്സിറ്റ് വിലാസം കാണിക്കുന്നു, കണ്ടെയ്നർ നിങ്ങളുടെ വീട്ടിലെ കണക്ഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു, ആരോ അതിനെ ലീക്ക് എന്ന് വിളിക്കുന്നു. ഒന്നും ലീക്ക് ചെയ്തിട്ടില്ല. ഹോസ്റ്റ് ടണൽ എന്നത് ഹോസ്റ്റിന്റെ നെറ്റ്‌വർക്ക് നെയിംസ്‌പേസിന് ഉള്ള ഇന്റർഫേസുകൾ, റൂട്ടുകൾ, നിയമങ്ങൾ എന്നിവയുടെ കൂട്ടമാണ്, ബ്രിഡ്ജിലുള്ള കണ്ടെയ്നർ സ്വന്തം ഡിഫോൾട്ട് റൂട്ടുള്ള മറ്റൊരു നെയിംസ്‌പേസാണ്. VPN ക്ലയന്റ് ആഴ്ചകളോളം കണക്റ്റ് ചെയ്തിരുന്നിട്ടും ഒരു കണ്ടെയ്നർ പാക്കറ്റ് പോലും അതിലേക്ക് കയറാത്ത ഒരു Compose സ്റ്റാക്കിൽ ഞാൻ ഇരുന്നിട്ടുണ്ട്.
ട്രേ ഐക്കണിന് മുമ്പ് നെയിംസ്‌പേസ് പരിശോധിക്കുക
നെയിംസ്‌പേസുകളാണ് മുഴുവൻ വാദം. Docker ഒരു ബ്രിഡ്ജ് നെറ്റ്‌വർക്കിൽ കണ്ടെയ്നർ ആരംഭിക്കുമ്പോൾ, അത് ഒരു നെറ്റ്‌വർക്ക് നെയിംസ്‌പേസ് സൃഷ്ടിക്കുന്നു, veth ജോടിയുടെ ഒരറ്റം അതിനുള്ളിൽ ഘടിപ്പിക്കുന്നു, ആ നെയിംസ്‌പേസിന് ഒരു വിലാസവും ഡിഫോൾട്ട് റൂട്ടും നൽകുന്നു. ടണൽ ഇന്റർഫേസ്, അതിനെ എന്ത് വിളിച്ചാലും, ഹോസ്റ്റിന്റെ നെയിംസ്‌പേസിലാണ് ജീവിക്കുന്നത്. കണ്ടെയ്നറിനുള്ളിലെ ട്രാഫികിന് അത് കാണാനാവില്ല, പുറത്തുനിന്ന് ഏതെങ്കിലും ക്ലയന്റ് ക്രമീകരണം അത് മാറ്റുന്നുമില്ല.
വേർപെടുത്തലിൽ നിന്ന് പുറത്തുകടക്കാൻ രണ്ട് പിന്തുണയുള്ള നീക്കങ്ങളുണ്ട്. --network host കണ്ടെയ്നറിനെ ഹോസ്റ്റിന്റെ നെയിംസ്‌പേസിനുള്ളിൽ ഇടുന്നു, അതിനാൽ അത് ഹോസ്റ്റിന്റെ റൂട്ടുകളും അതുവഴി ടണലും പിന്തുടരുന്നു. --network container:vpn മറ്റൊരു കണ്ടെയ്നറിന്റെ നെയിംസ്‌പേസ് പങ്കിടുന്നു, ഒപ്പം ഭൂരിഭാഗം സൈഡ്കാർ രൂപകൽപ്പനകളും വർക്ക്ലോഡ് ഒരു VPN കണ്ടെയ്നർ വഴി അയക്കുന്നത് ഇങ്ങനെയാണ്. രണ്ടും വ്യക്തമായ തിരഞ്ഞെടുപ്പുകളാണ്; സാധാരണയായി അവയിൽ ഒന്ന് മാത്രമാണ് വിന്യസിക്കുന്നയാളുടെ ഉദ്ദേശ്യം.
ഹോസ്റ്റ് മോഡ് സൗജന്യ അപ്ഗ്രേഡല്ല. കണ്ടെയ്നർ സ്വന്തം വിലാസം ഉണ്ടായിരിക്കുന്നത് നിർത്തുന്നു, പോർട്ട് പ്രസിദ്ധീകരണം ബാധകമല്ലാതാകുന്നു, അവിടെ NET_ADMIN ഉള്ള ഒരു പ്രോസസ്സിന് ഹോസ്റ്റിന്റെ റൗട്ടിംഗ് മാറ്റിയെഴുതാനാകും. അത് സ്വീകരിക്കുന്നത് ശരിയായ തീരുമാനമായേക്കാം. ഇത് ഇതിനകം ഓണാണെന്ന് അനുമാനിക്കുന്നതാണ്, ഒരിക്കലും വഴിയിൽ ഇല്ലാത്ത ഒരു ടണൽ ആളുകൾ ഒരു വൈകുന്നേരം ഡീബഗ് ചെയ്യാൻ കാരണം.
പാക്കറ്റിനെ ബ്രിഡ്ജിൽ നിന്ന് പുറത്തേക്ക് പിന്തുടരുക
ബ്രിഡ്ജ് കണ്ടെയ്നർ അതിന്റെ പാക്കറ്റ് സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്‌വേയിലേക്ക് അയക്കുന്നു, അത് ഹോസ്റ്റിലെ ബ്രിഡ്ജ് ഇന്റർഫേസാണ്. തുടർന്ന് ഹോസ്റ്റ് പാക്കറ്റ് കൈമാറുന്നു, ഡിഫോൾട്ട് കോൺഫിഗറേഷനിൽ പാക്കറ്റ് പുറത്തുപോകുന്നതിന് മുമ്പ് ഉറവിട വിലാസം സ്വന്തം വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുന്നു. ആ വിവർത്തന ഘട്ടമാണ് നയത്തെ നിശബ്ദമായി തോൽപ്പിക്കുന്നത്.
പാക്കറ്റ് ടണലിന്റെ അവസാന ബിന്ദുവിൽ എത്തുമ്പോൾ അത് ഹോസ്റ്റിന്റെ വിലാസം വഹിക്കുന്നു. കണ്ടെയ്നറിന്റെ യഥാർത്ഥ വിലാസത്തെ ആശ്രയിക്കുന്ന ഏതെങ്കിലും നിയമം, പോളിസി റൂട്ട് അല്ലെങ്കിൽ വിഭജിത ടണൽ തീരുമാനം പൊരുത്തപ്പെടുന്നത് നിർത്തുന്നു, വ്യത്യസ്ത എക്സിറ്റുകളിലൂടെ പുറത്തുപോകേണ്ട രണ്ട് കണ്ടെയ്നറുകളെ ഉറവിടം മാത്രം കൊണ്ട് വേർതിരിച്ചറിയാനാവില്ല. നിങ്ങൾക്ക് ഓരോ കണ്ടെയ്നറിനും റൗട്ടിംഗ് വേണമെങ്കിൽ, തീരുമാനം വിവർത്തനത്തിന് മുമ്പോ നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു നെയിംസ്‌പേസിനുള്ളിലോ എടുക്കണം.
Docker ഈ നിയമങ്ങൾ സ്വയം പരിപാലിക്കുന്നു, ഡീമൺ ഏത് ഫയർവാൾ ബാക്കെൻഡുമായി കോൺഫിഗർ ചെയ്യപ്പെട്ടിട്ടുണ്ടോ അതിലൂടെ. കൈമാറ്റം ചെയ്യുന്ന ട്രാഫിക്കിനുള്ള പിന്തുണയുള്ള ഹൂക്കിന് പുറത്ത് കൈകൊണ്ട് എഴുതിയ നിയമങ്ങൾ, DOCKER-USER, ഡീമൺ റീസ്റ്റാർട്ട് ചെയ്യുമ്പോഴോ ഹോസ്റ്റ് അപ്ഗ്രേഡ് ചെയ്യുമ്പോഴോ പുനഃക്രമീകരിക്കപ്പെടുകയോ ഒഴിവാക്കപ്പെടുകയോ ചെയ്യാം. പാക്കറ്റ് ഫിൽട്ടറിംഗിനെക്കുറിച്ചുള്ള Docker ഡോക്യുമെന്റേഷൻ ചെയിനുകളുടെ ക്രമം കാണിക്കുന്നു; പ്രായോഗിക കാര്യം, ഓരോ നിയമത്തിനും ഒരു ഉടമയും നിങ്ങൾ യഥാർത്ഥത്തിൽ പരീക്ഷിച്ച ഒരു റീലോഡ് പാതയും വേണം എന്നതാണ്.
രണ്ട് സിസ്റ്റങ്ങളും വെവ്വേറെ പരീക്ഷിക്കുക
ഒരു നെയിംസ്‌പേസിലെ തെളിവുകൾ മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. VPN കണ്ടെയ്നറിനുള്ളിൽ പ്രവർത്തിപ്പിച്ച അഭ്യർത്ഥന ആ കണ്ടെയ്നറിന് ടണൽ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. അത് ഹോസ്റ്റിനെക്കുറിച്ചുള്ള തെളിവല്ല, --network host കണ്ടെയ്നറിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുന്ന അതേ കമാൻഡ് ബ്രിഡ്ജിനെക്കുറിച്ചുള്ള തെളിവുമല്ല.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'തുടർന്ന് പരീക്ഷണം സമാനമായ ഇമേജിലല്ല, യഥാർത്ഥ ആപ്ലിക്കേഷൻ കണ്ടെയ്നറിനുള്ളിൽ ആവർത്തിക്കുക. ആപ്പിൽ അധിക റൂട്ടോ പ്രോക്സി എൻവയോൺമെന്റ് വേരിയബിളോ മറ്റൊരു റിസോൾവറോ ഉണ്ടാകാം, അവയിൽ ഓരോന്നും ഉത്തരം മാറ്റുന്നു. ഓരോ തവണയും നാമ പരിഹാരവും രണ്ടാമത്തെ വിലാസ കുടുംബവും പരിശോധിക്കുക: ഉപയോക്താവ് നിർവചിച്ച ബ്രിഡ്ജുകളിലെ കണ്ടെയ്നറുകൾ Docker-ന്റെ ബിൽറ്റ്-ഇൻ റിസോൾവർ വഴി 127.0.0.11-ൽ പരിഹരിക്കപ്പെടുന്നു, ബ്രിഡ്ജിലെ IPv6 ഡിഫോൾട്ട് റൂട്ടിന് നിങ്ങൾ IPv4 മാത്രമുള്ള ടണൽ പരീക്ഷിക്കുന്നതിൽ മുഴുകിയിരിക്കുമ്പോൾ ട്രാഫിക് പുറത്തുകൊണ്ടുപോകാനാകും.
ക്രെഡൻഷ്യലുകൾ തൊടുന്നതിന് മുമ്പ് പാറ്റേൺ വായിക്കുക
ഹോസ്റ്റ് പ്രവർത്തിക്കുകയും കണ്ടെയ്നർ പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുമ്പോൾ, കാരണം ഏതാണ്ട് എപ്പോഴും ഘടനാപരമാണ്, കീകൾ കറക്കുന്നതോ ക്ലയന്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതോ ഒരു ഉച്ചയ്ക്ക് ശേഷം പാഴാക്കുന്നു. ആദ്യം ലക്ഷണം ക്രമീകരിക്കുക, പരിഹാരം സാധാരണയായി സ്വയം പേര് പറയും.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
ഓവർലാപ്പ് വരിക്ക് സ്വന്തമായി ഒരു വാക്യം അർഹതയുണ്ട്. 172.17.0.0/16-ലേക്കോ, നിങ്ങളുടെ ബ്രിഡ്ജ് പ്രിഫിക്സ് യാദൃച്ഛികമായി അടങ്ങുന്ന 10.0.0.0/8-ലേക്കോ റൂട്ട് തള്ളുന്ന VPN പ്രൊഫൈൽ ടണലിനെ കണ്ടെയ്നർ സബ്നെറ്റ് ക്ലെയിം ചെയ്യാൻ പ്രേരിപ്പിക്കുന്നു, വിവർത്തനം ചെയ്ത വിലാസങ്ങളിലേക്കുള്ള മറുപടികൾ തെറ്റായ ദിശയിലേക്ക് പോകുകയോ അപ്രത്യക്ഷമാകുകയോ ചെയ്യും. Docker നെറ്റ്‌വർക്ക് പുനഃസംഖ്യയിടുന്നത് സാധാരണയായി ഒഴിവാക്കലുകൾ കൂട്ടിവയ്ക്കുന്നതിനേക്കാൾ വൃത്തിയാണ്.
കവറേജ് വ്യക്തമാക്കുക, തുടർന്ന് മനഃപൂർവം അത് തകർക്കുക
രണ്ട് രൂപകൽപ്പനകൾ അവലോകനത്തിൽ നിലനിൽക്കുന്നു. VPN കണ്ടെയ്നറിന്റെ നെയിംസ്‌പേസ് പങ്കിടുക, ഉൾപ്പെടുത്തിയ ഓരോ വർക്ക്ലോഡും ഒരു റീസ്റ്റാർട്ട് അതിർത്തിയുള്ള ഒരു ടണൽ ഉപയോഗിക്കുന്നു, ഒരു സേവനത്തിന് മറ്റൊരു എക്സിറ്റോ സ്വന്തം DNS പാതയോ ആവശ്യമാകുന്നതുവരെ ഇത് ലളിതമാണ്. അല്ലെങ്കിൽ കണ്ടെയ്നർ നെറ്റ്‌വർക്ക് ഹോസ്റ്റിലെ ഒരു VPN ഗേറ്റ്‌വേയിലേക്ക് റൂട്ട് ചെയ്യുക: ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമം, ബ്രിഡ്ജ് പ്രിഫിക്സ് ടണലിലേക്ക്, തിരിച്ചുവരുന്ന ട്രാഫിക് വ്യക്തമായി കൈകാര്യം ചെയ്തു. ഇത് ഓരോ നെറ്റ്‌വർക്കിനും നിയന്ത്രണം വാങ്ങുന്നു, ഡീമൺ, ക്ലയന്റ് അപ്ഗ്രേഡുകൾക്കിടയിൽ പരിപാലിക്കേണ്ട ഒരു നിയമക്കൂട്ടം നിങ്ങൾക്ക് ചെലവാക്കുന്നു.
ഏതായാലും, പ്രധാനമായ പരീക്ഷണം പരാജയ സന്ദർഭമാണ്. കണ്ടെയ്നർ അഭ്യർത്ഥന വഴിയിലിരിക്കുമ്പോൾ ടണൽ നിർത്തുക, പാക്കറ്റ് എവിടേക്ക് പോകുന്നു എന്ന് നോക്കുക. അത് നേരിട്ടുള്ള പാതയിലേക്ക് തിരികെ വീഴുകയാണെങ്കിൽ, കവറേജ് ഒരിക്കലും നടപ്പാക്കിയിട്ടില്ല, കാരണം ക്ലയന്റിന്റെ kill switch ക്ലയന്റിന്റെ സ്വന്തം ട്രാഫിക്കിനെയാണ് നിയന്ത്രിക്കുന്നത്, ബ്രിഡ്ജിൽ നിന്ന് ഫോർവേഡ് ചെയ്യുന്ന പാക്കറ്റുകളെയല്ല. തുടർന്ന് ഡീമണും ഹോസ്റ്റും റീസ്റ്റാർട്ട് ചെയ്ത് ഫലം രണ്ടാമതും സ്ഥിരീകരിക്കുക; കൈകൊണ്ട് എഴുതിയ നിയമങ്ങൾ അപ്രത്യക്ഷമാകുന്ന നിമിഷം അതാണ്.
അത് പൂർത്തിയായി എന്ന് പറയുന്നതിന് മുമ്പ് നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: ടണൽ ഇന്റർഫേസ് ട്രാഫിക്കിന്റെ അതേ നെയിംസ്‌പേസിലാണ്, കണ്ടെയ്നർ പരീക്ഷണം യഥാർത്ഥ കണ്ടെയ്നറിനുള്ളിൽ നടന്നു, നാമ പരിഹാരവും രണ്ട് വിലാസ കുടുംബങ്ങളും പരിശോധിച്ചു, ടണൽ പരാജയ പരീക്ഷണം ഇപ്പോഴും അടച്ച രീതിയിൽ പരാജയപ്പെടുന്നു. തുടർന്ന് ഫയർവാൾ ബാക്കെൻഡ്, ക്ലയന്റ് പതിപ്പ്, ഓരോ നിയമത്തിന്റെയും ഉടമ എന്നിവ എഴുതുക. ആ രേഖയാണ് അടുത്ത അപ്ഗ്രേഡിനെ പഴയ അനുമാനങ്ങളുടെ രേഖപ്പെടുത്താത്ത മിശ്രിതം അവശേഷിപ്പിക്കുന്നതിൽ നിന്ന് തടയുന്നത്.