VPN ਕੰਟੇਨਰ ਵਿੱਚ NET_ADMIN: ਇਹ ਕੀ ਅਤੇ ਕਿੱਥੇ ਬਦਲ ਸਕਦਾ ਹੈ

NET_ADMIN ਲੀਨਕਸ ਦੀ ਉਹ ਸਮਰੱਥਾ ਹੈ ਜੋ ਕਿਸੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਨ ਕਰਨ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਵਿੱਚ ਇਹ ਠੀਕ ਉਹੀ ਉਸ ਨੈੱਟਵਰਕ ਨਾਮਸਥਾਨ ਦੇ ਅੰਦਰ ਕਰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਚੱਲਦੀ ਹੈ। ਇਹ ਸਾਕਟ ਖੋਲ੍ਹਣ ਦਾ ਲਾਇਸੰਸ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਡਿਵਾਈਸ ਜਾਂ ਰੂਟ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। ਦਿਲਚਸਪ ਸਵਾਲ ਕਦੇ ਵੀ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਸਮਰੱਥਾ ਦਿੱਤੀ ਗਈ ਹੈ ਜਾਂ ਨਹੀਂ, ਬਲਕਿ ਇਹ ਕਿ ਬਦਲਾਅ ਕਿਹੜੇ ਨਾਮਸਥਾਨ ਨੂੰ ਮਿਲਦਾ ਹੈ।

ਸਮਰੱਥਾ ਕੀ ਕਵਰ ਕਰਦੀ ਹੈ

ਆਪਣੇ ਨਾਮਸਥਾਨ ਦੇ ਅੰਦਰ NET_ADMIN ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਇੰਟਰਫੇਸ ਉੱਪਰ ਅਤੇ ਹੇਠਾਂ ਕਰ ਸਕਦੀ ਹੈ, ਪਤੇ ਅਲਾਟ ਕਰ ਸਕਦੀ ਹੈ, ਰੂਟ ਜੋੜ ਤੇ ਹਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਿਖ ਸਕਦੀ ਹੈ, ਜੋ ਉਹਨਾਂ ਕਿਰਿਆਵਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ capabilities(7) ਇਸ ਸਮਰੱਥਾ ਹੇਠ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਇਹ ਇੰਟਰਫੇਸ-ਪੱਧਰ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਵੀ ਸਮਾਇਓਜਿਤ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਰਨਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਵੇਂ ਕਤਾਰ ਵਿੱਚ ਪਾਉਂਦਾ ਅਤੇ ਫਿਲਟਰ ਕਰਦਾ ਹੈ। VPN ਕਲਾਇੰਟ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਲੋੜੀਂਦੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਇਸ ਲਈ ਜ਼ਿਆਦਾਤਰ ਇਮੇਜ ਵਰਤੋਂ ਨਾਲੋਂ ਵੱਧ ਪਹੁੰਚ ਮੰਗਦੀਆਂ ਹਨ।

ਉਸ ਨਾਮਸਥਾਨ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਕਿਰਿਆਵਾਂ ਕਵਰ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਅਤੇ ਨੇੜਲੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵੱਖਰੇ ਹਨ। ਕੱਚੇ ਪੈਕੇਟ ਪੜ੍ਹਨਾ ਅਤੇ ਲਿਖਣਾ NET_RAW ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ tun ਡਿਵਾਈਸ ਬਣਾਉਣ ਲਈ ਸਮਰੱਥਾ ਅਤੇ ਡਿਵਾਈਸ ਨੋਡ ਤੱਕ ਪਹੁੰਚ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹਨ। ਡਿਵਾਈਸ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਇਜਾਜ਼ਤ ਦੀ ਗਲਤੀ ਮਿਲਦੀ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਵਰਗੀ ਲੱਗਦੀ ਹੈ ਅਤੇ ਨਹੀਂ ਹੈ।

ਨਾਮਸਥਾਨ ਨੁਕਸਾਨ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰਦਾ ਹੈ

ਆਪਣੇ ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕੰਟੇਨਰ ਆਪਣੇ loopback, ਆਪਣੇ ਇੰਟਰਫੇਸ ਅਤੇ ਆਪਣੀ ਰੂਟਿੰਗ ਟੇਬਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਉੱਥੇ NET_ADMIN ਦੇਣ ਨਾਲ VPN ਕਲਾਇੰਟ ਹੋਸਟ ਦੇ ਰੂਟਿੰਗ ਫੈਸਲਿਆਂ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਟਨਲ ਬਣਾ ਸਕਦਾ ਹੈ, ਜੋ ਉਹ ਵਿਵਸਥਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕੰਟੇਨਰ ਇਮੇਜ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ।

ਉਸ ਕੰਟੇਨਰ ਨੂੰ ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਉੱਤੇ ਲੈ ਜਾਓ ਅਤੇ ਉਹੀ ਆਗਿਆ ਹੁਣ ਹੋਸਟ ਦੇ ਰੂਟ ਅਤੇ ਹੋਸਟ ਦੇ ਫਾਇਰਵਾਲ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਵੱਖਰਾ ਨਾਮਸਥਾਨ ਬਚਿਆ ਨਹੀਂ। ਜਿਸ ਕਲਾਇੰਟ ਨੇ ਇੱਕ ਟਨਲ ਸੰਭਾਲਣੀ ਸੀ ਉਹ ਪੂਰੀ ਮਸ਼ੀਨ ਦਾ ਟ੍ਰੈਫਿਕ ਮੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸਦੀ ਟੀਅਰਡਾਊਨ ਸਕ੍ਰਿਪਟ ਦੀ ਗਲਤੀ ਹੋਸਟ ਉੱਤੇ ਉਹ ਨਿਯਮ ਛੱਡ ਜਾਂਦੀ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਲਿਖੇ। ਸਮਰੱਥਾ ਵਿੱਚ ਆਪ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ; ਸੰਦਰਭ ਬਦਲਿਆ। ਇਸ ਲਈ ਉਹੀ compose ਫਾਇਲ ਦੋ ਹੋਸਟਾਂ ਉੱਤੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ।

ਇੱਕ ਵਿੱਚ ਮਿਲਣ ਵਾਲੀਆਂ ਤਿੰਨ ਪੂਰਵ ਸ਼ਰਤਾਂ

VPN ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਸਟਾਰਟਅੱਪ ਫੇਲ੍ਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਸਬੰਧਤ ਹੁੰਦੇ ਹਨ: ਸਮਰੱਥਾ, ਟਨਲ ਡਿਵਾਈਸ ਅਤੇ ਪ੍ਰੋਟੋਕਾਲ ਲਈ ਕਰਨਲ ਸਹਿਯੋਗ। ਤਿੰਨੇ ਇਕੱਠੇ ਦੇਣ ਨਾਲ ਕੰਮ ਬਣਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਗਲੀ ਫੇਲ੍ਹ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਣਾ ਵੀ ਅਸੰਭਵ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ compose ਟੁਕੜਾ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਡਿਵਾਈਸ ਨੋਡ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਭੇਜਦਾ ਹੈ:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

ਇਮੇਜ ਦੇ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਪੜ੍ਹੋ ਕਿ ਕਿਹੜੇ sysctl ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਵਿੱਚ sysctl ਨੂੰ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਜਾਂ ਹੋਸਟ-ਪੱਧਰ ਦੀ ਸੈਟਿੰਗ ਚਾਹੀਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਜਿੱਥੇ ਇਮੇਜ ਸਿਰਫ਼ ਯੂਜ਼ਰ-ਸਪੇਸ ਮੋਡ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਉੱਥੇ ਡਿਵਾਈਸ ਦੀ ਲੋੜ ਹੀ ਨਹੀਂ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਦੀ ਸੂਚੀ ਉਸੇ ਅਨੁਪਾਤ ਵਿੱਚ ਘਟਦੀ ਹੈ।

ਮੋਡ ਨਹੀਂ, ਸੰਕੁਚਿਤ ਕਿਰਿਆ ਦਿਓ

ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲਾ ਮੋਡ ਹਰ ਸਮਰੱਥਾ ਸੌਂਪਦਾ ਹੈ ਅਤੇ ਉਸੇ ਸਮੇਂ ਡਿਵਾਈਸ ਪਹੁੰਚ ਨੂੰ ਚੌੜਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਤਿੰਨ ਪੂਰਵ ਸ਼ਰਤਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਗੁੰਮ ਸੀ। ਇਹ ਕੰਟੇਨਰ ਦੀਆਂ ਫੇਲ੍ਹ ਦੀਆਂ ਢੰਗਾਂ ਨੂੰ ਹੋਸਟ ਬਦਲਾਵਾਂ ਤੋਂ ਵੱਖ ਨਾ ਕੀਤਾ ਜਾ ਸਕਣ ਵਾਲਾ ਵੀ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਲਿਖਣ ਵਿੱਚ ਲੰਮੀ ਹੋਵੇ ਤਾਂ ਵੀ ਸਪਸ਼ਟ ਸੂਚੀ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।

ਰੂਟਲੈੱਸ ਅਤੇ ਯੂਜ਼ਰ-ਨਾਮਸਥਾਨ ਤੈਨਾਤੀਆਂ ਵਿਵਹਾਰ ਵਿੱਚ ਸਮਰੱਥਾ ਦਾ ਅਰਥ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਇਸਨੂੰ ਸਿਰਫ਼ ਮੈਪ ਕੀਤੇ ਨਾਮਸਥਾਨ ਦੇ ਅੰਦਰ ਹੀ ਰੱਖ ਸਕਦੀ ਹੈ। ਰੂਟਫੁੱਲ ਉਦਾਹਰਨ ਤੋਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਸੂਚੀ ਰੂਟਲੈੱਸ ਰਨਟਾਈਮ ਵਿੱਚ ਕਾਪੀ ਕਰਕੇ ਉਹੀ ਪਹੁੰਚ ਦੀ ਆਸ ਰੱਖਣਾ ਦੁਪਹਿਰ ਗੁਆਉਣ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ।

ਭੇਦ ਵੱਖਰੇ ਫੈਸਲੇ ਦੀ ਗੱਲ ਹਨ। NET_ADMIN ਰੱਖਣਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਕਲਾਇੰਟ ਕਿਹੜੀ ਪੀਅਰ ਪਛਾਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਲੋਡ ਕਰਦਾ ਹੈ ਜਾਂ ਉਹ ਕਿਵੇਂ ਘੁੰਮਾਏ ਜਾਂਦੇ ਹਨ। ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਨ ਭਰੋਸਾ ਨਹੀਂ ਦਿੰਦਾ।

ਬਦਲਾਅ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਆਗਿਆ ਕਿਉਂ ਹੈ

ਟਨਲ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੰਟੇਨਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਮਿਲਿਆ। ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਂਚ ਜੋੜੀਆਂ ਗਈਆਂ ਸਮਰੱਥਾਵਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਮੋਡ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਫਿਰ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਅੰਦਰੋਂ ਇੰਟਰਫੇਸ ਸੂਚੀ ਕਿਹੋ ਜਿਹੀ ਦਿਸਦੀ ਹੈ:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

ਜੇ ਸਮਰੱਥਾ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇੰਟਰਫੇਸ ਸੂਚੀ ਅਜੇ ਵੀ ਖਾਲੀ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਕੁਝ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਗਿਆ, ਅਤੇ ਅੱਗੇ ਵੇਖਣ ਦੀ ਥਾਂ ਕੰਟੇਨਰ ਲੌਗ ਹਨ। ਜੇ ਟਨਲ ਮੌਜੂਦ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਵਹਿੰਦਾ, ਤਾਂ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਦੀ ਰੂਟਿੰਗ ਟੇਬਲ ਅਗਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

ਟੀਅਰਡਾਊਨ ਰਾਹ ਵੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਿਖਣ ਵਾਲਾ ਕਲਾਇੰਟ ਉਹਨਾਂ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਸਕਦਾ ਹੈ। ਕੰਟੇਨਰ ਰੋਕੋ ਅਤੇ ਜੇ ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ ਤਾਂ ਹੋਸਟ ਦੇ ਨਿਯਮ ਸਮੂਹ ਨੂੰ ਮੁੜ ਜਾਂਚੋ। ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਿਰਫ਼ ਦੋ ਸਕਿੰਟ ਲੋੜੀਂਦੀ ਆਗਿਆ ਨੂੰ compose ਫਾਇਲ ਵਿੱਚ ਇਸਨੂੰ ਸਮਝਾਉਣ ਵਾਲੀ ਨੋਟ ਤੋਂ ਬਿਨਾਂ ਸਥਾਈ ਲੋੜ ਵਜੋਂ ਨਹੀਂ ਦਰਸਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ।

ਹਰ ਸਮਰੱਥਾ ਦੇ ਕੋਲ ਕਾਰਨ ਲਿਖੋ: ਕਿਹੜੀ ਕਿਰਿਆ ਨੂੰ ਇਸਦੀ ਲੋੜ ਸੀ ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਉਹ ਨੋਟ ਇਮੇਜ ਅੱਪਡੇਟਾਂ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਸਮੀਖਿਆ ਕੀਤੀ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਸੂਚੀ ਅਤੇ ਕਾਪੀ-ਪੇਸਟ ਨਾਲ ਵਧੀ ਸੂਚੀ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੈ।