Docker-ൽ OpenVPN: ഏറ്റവും ചെറിയ ക്ലയന്റിന് ആവശ്യമായ റൺടൈം കരാർ

പരിശോധിച്ച ഇമേജ്, ഒരു സംരക്ഷിത പ്രൊഫൈൽ, TUN ആക്സസ്, NET_ADMIN. കണ്ടെയ്നർ എന്ത് നേടുന്നു, എന്ത് നേടരുത്, ടണൽ പ്രവർത്തിക്കുന്നു എന്ന് എങ്ങനെ തെളിയിക്കാം.

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

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

കണ്ടെയ്നർ എന്ത് നേടുന്നു, എന്ത് നേടുന്നില്ല

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

services:
  vpn:
    image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./vpn:/vpn:ro
    working_dir: /vpn
    entrypoint: ["openvpn"]
    command: ["--config", "/vpn/client.ovpn"]

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

ഇവിടെ വായനയ്ക്ക് മാത്രം എന്നാൽ കണ്ടെയ്നറിന് നിങ്ങളുടെ ഹോസ്റ്റ് ഫയലുകൾ മാറ്റാൻ കഴിയില്ല എന്നാണ്; നിങ്ങൾ മൗണ്ട് ചെയ്ത സ്വകാര്യ കീ വായിക്കാൻ കഴിയില്ല എന്നല്ല. അതാണ് മൗണ്ടിന്റെ മുഴുവൻ ഉദ്ദേശ്യം, അതുകൊണ്ടാണ് ഫയൽ അനുമതികളും ഉടമസ്ഥതയും രഹസ്യം ഹോസ്റ്റിലേക്ക് എങ്ങനെ എത്തി എന്നതും ഇപ്പോഴും പ്രധാനമാകുന്നത്. കമാൻഡ് ലൈനിൽ ഒരിക്കലും പാസ്വേഡ് നൽകരുത്, ഇമേജ് ലെയറിൽ ചുട്ടെടുക്കരുത്, കാരണം രണ്ടും പിന്നീട് വൃത്തിയാക്കാൻ കഴിയാത്ത സ്ഥലങ്ങളിൽ നിലനിൽക്കുന്നു.

കഴിവുകൾ, entrypoint, അവയ്ക്കിടയിലെ കെണി

രണ്ട് ക്രമീകരണങ്ങൾ ആവശ്യമാണ്, അവ പരസ്പരബന്ധമില്ലാത്ത ജോലികൾ ചെയ്യുന്നു. NET_ADMIN കണ്ടെയ്നറിന്റെ നെയിംസ്പേസിനുള്ളിൽ ഇന്റർഫേസുകളും റൂട്ടുകളും കൈകാര്യം ചെയ്യാൻ അനുവദിക്കുന്നു. /dev/net/tun ഡിവൈസ് എൻട്രി പ്രോസസിന് ടണൽ ഡിവൈസ് പോലും തുറക്കാൻ അനുവദിക്കുന്നു. ഒന്ന് മറ്റൊന്നില്ലാതെ നൽകിയാൽ വ്യക്തമായ പരാജയം ഉണ്ടാകും, അത് സൗകര്യപ്രദമാണ്: ഇല്ലാത്ത TUN ഡിവൈസ് തുറക്കുമ്പോൾ പരാജയപ്പെടുന്നു, അതേസമയം ഇല്ലാത്ത കഴിവ് ക്ലയന്റ് ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ പരാജയപ്പെടുന്നു.

ഇവയൊന്നും privileged: true ന്യായീകരിക്കുന്നില്ല. പ്രിവിലേജ് ഉള്ള കണ്ടെയ്നർ എല്ലാ കഴിവുകളും ഡിവൈസ് ആക്സസും നേടുന്നു, ഇത് ഈ വർക്ക്ലോഡിന് ആവശ്യമുള്ളതിനേക്കാൾ വളരെ വലിയ അനുമതിയാണ്. റൺടൈം പ്രിവിലേജുകളും കഴിവുകളും സംബന്ധിച്ച റഫറൻസ് ഈ അനുമതി എത്രത്തോളം എത്തുന്നു എന്ന് വിശദീകരിക്കുന്നു. ഒരു chart അല്ലെങ്കിൽ ബ്ലോഗ് പോസ്റ്റ് അത് ആവശ്യപ്പെടുന്നുവെങ്കിൽ, ആവശ്യകത യഥാർത്ഥത്തിൽ ഇല്ലാത്ത ഡിവൈസ് പാതയായിരുന്നോ ഇല്ലാത്ത കഴിവായിരുന്നോ എന്ന് ആദ്യം പരിശോധിക്കുക.

entrypoint ഓവർറൈഡ് ചെയ്യുന്നതാണ് കടിക്കുന്ന ഭാഗം. openvpn നേരിട്ട് വിളിക്കുന്നത് സാധാരണ ഇമേജിന് ശരിയാണ്, ഡെമൺ പ്രവർത്തിപ്പിക്കുന്നതിന് മുൻപ് ഫയർവാൾ നിയമങ്ങളും റിസോൾവർ ഫയലുകളും ക്രെഡൻഷ്യലുകളും തയ്യാറാക്കുന്ന ഏത് ഉൽപ്പന്ന ഇമേജിനും തെറ്റാണ്. ആ സ്ക്രിപ്റ്റ് ഓവർറൈഡ് ചെയ്യുന്നത് തയ്യാറെടുപ്പ് ഒഴിവാക്കി, പകുതി കോൺഫിഗർ ചെയ്ത നെയിംസ്പേസിൽ ഉയർന്ന ടണൽ ഡീബഗ് ചെയ്യാൻ വിടുന്നു.

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

നെയിംസ്പേസിനുള്ളിൽ നിന്ന് പരിശോധിക്കുക, ഹോസ്റ്റിൽ നിന്നല്ല

സ്റ്റാക്ക് ഉയർത്തുക, ക്ലയന്റ് ബന്ധിപ്പിച്ച അവസ്ഥയിലെത്തിയെന്ന് ലോഗിൽ സ്ഥിരീകരിക്കുക, തുടർന്ന് ടണൽ യഥാർത്ഥത്തിൽ കൈവശം വയ്ക്കുന്ന നെയിംസ്പേസ് പരിശോധിക്കുക.

docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route

വിലാസ ലിസ്റ്റിൽ പൂളിൽ നിന്നുള്ള വിലാസമുള്ള ടണൽ ഇന്റർഫേസ് കാണണം, റൂട്ട് ടേബിളിൽ അതിലേക്ക് ചൂണ്ടുന്ന പുഷ് ചെയ്ത ലക്ഷ്യസ്ഥാനങ്ങൾ കാണണം. ഇന്റർഫേസ് ഇല്ലെങ്കിൽ, ക്ലയന്റ് അത് സൃഷ്ടിക്കുന്ന ഘട്ടത്തിലെത്തിയിട്ടില്ല. അത് ഉണ്ടെങ്കിലും ഒരു റൂട്ടും അത് ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, തിരയേണ്ട സ്ഥലം push അല്ലെങ്കിൽ റൂട്ട് ഓപ്ഷനുകളാണ്.

തുടർന്ന് നിങ്ങൾക്ക് പ്രധാനമായ ലക്ഷ്യസ്ഥാനം ടണൽ ഉപയോഗിക്കേണ്ട നെയിംസ്പേസിൽ നിന്ന്, ping മാത്രമല്ല ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച് പരീക്ഷിക്കുക. പേര് പരിഹരിക്കൽ വേറിട്ട പരാജയമാണ്, അത് വ്യക്തമായി പരീക്ഷിക്കേണ്ടതാണ്: പുഷ് ചെയ്ത DNS വിലാസം കണ്ടെയ്നറിന്റെ റിസോൾവറിനെ സ്വയം പുതുക്കുന്നില്ല, push അവഗണിക്കുന്ന സ്വതന്ത്ര ക്ലയന്റ് ഇമേജ് കോൺഫിഗർ ചെയ്തതിലൂടെ പേരുകൾ പരിഹരിക്കും.

വിച്ഛേദിച്ച അവസ്ഥ കരാറിന്റെ ഭാഗമാണ്

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

വർക്ക്ലോഡ് ഒരിക്കലും സാധാരണ പാത ഉപയോഗിക്കരുതെന്നുണ്ടെങ്കിൽ, ഫയർവാൾ നിയമങ്ങളും നെയിംസ്പേസിനുള്ളിലെ സന്നദ്ധ സിഗ്നലും ഉപയോഗിച്ച് അത് വ്യക്തമായി രൂപകൽപ്പന ചെയ്യുക. Kill switch നിങ്ങൾ എഴുതി പരിശോധിക്കുന്ന നയമാണ്, കണ്ടെയ്നറിൽ ക്ലയന്റ് പ്രവർത്തിപ്പിച്ച് പാരമ്പര്യമായി ലഭിക്കുന്ന സ്വഭാവമല്ല.

അവസാനമായി, പരിധി ഓർക്കുക: ഈ റൂട്ടുകൾ കണ്ടെയ്നറിന്റെ നെയിംസ്പേസിൽ ജീവിക്കുന്നു, ഹോസ്റ്റിന്റെ റൗട്ടിംഗ് ടേബിൾ മാറ്റിസ്ഥാപിക്കുന്നില്ല. Docker-ന്റെ ഫോർവേഡിംഗ്, വിവർത്തനം, ഫയർവാൾ നിയമങ്ങൾ പുറം പാതയുടെ ഭാഗമായി തുടരുന്നു, പ്രസിദ്ധീകരിച്ച പോർട്ട് VPN ഇന്റർഫേസല്ല.

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