Docker ਵਿੱਚ OpenVPN /dev/net/tun ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ: ਕੀ ਗੁੰਮ ਹੈ

ਕੰਟੇਨਰ ਇਮੇਜਾਂ ਆਪਣੇ ਲੋੜੀਂਦੇ ਹਰ OpenVPN ਬਾਈਨਰੀ ਅਤੇ ਸੰਰਚਨਾ ਫਾਈਲ ਨਾਲ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਪਹਿਲੀ ਨੈੱਟਵਰਕ ਕਾਲ 'ਤੇ ਅਸਫਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਗਲਤੀ /dev/net/tun ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਕਰਨਲ ਨੂੰ TUN ਇੰਟਰਫੇਸ ਮੰਗਿਆ ਸੀ ਅਤੇ ਕੰਟੇਨਰ ਕੋਲ ਨਾ ਡਿਵਾਈਸ ਨੋਡ ਸੀ ਅਤੇ ਨਾ ਹੀ ਉਹ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ। ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਇਜਾਜ਼ਤਾਂ ਹਨ, ਅਤੇ ਇੱਕ ਸੁਧਾਰਨ ਨਾਲ ਦੂਜੀ ਠੀਕ ਉੱਥੇ ਹੀ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਸੀ।

ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਲਈ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਕਮਾਂਡ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਦਾ ਗਲਤੀ ਸੁਨੇਹਾ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਸੀਮਾ 'ਤੇ ਖੜ੍ਹੇ ਸੀ।

ਡਿਵਾਈਸ ਨੋਡ ਅਤੇ ਸਮਰੱਥਾ ਦੋ ਦਰਵਾਜ਼ੇ ਹਨ

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

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

ਇਸਨੂੰ Compose ਫਾਈਲ ਤੋਂ ਬਾਹਰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ

ਸੇਵਾ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਹੋਸਟ ਕੋਲ ਡਿਵਾਈਸ ਹੈ ਅਤੇ ਨੰਗਾ ਕੰਟੇਨਰ ਇੰਟਰਫੇਸ ਬਣਾ ਸਕਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਕਮਾਂਡ ਜਾਣ-ਬੁੱਝ ਕੇ ਘੱਟੋ-ਘੱਟ ਹੈ, ਅਤੇ ਇਸਦਾ ਇੱਕੋ ਇੱਕ ਮਕਸਦ ਹੋਸਟ ਸਮੱਸਿਆ ਨੂੰ compose ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨਾ ਹੈ। ਜੇ ਇਹ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਕੋਈ ਵੀ compose ਬਦਲਾਅ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

ਹੋਸਟ 'ਤੇ ਨੋਡ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ tun ਮਾਡਿਊਲ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਜੋ ਕੰਟੇਨਰ ਦੀ ਨਹੀਂ ਸਗੋਂ ਹੋਸਟ ਪਾਸੇ ਦੀ ਮੁਰੰਮਤ ਹੈ। ਨੋਡ ਹੋਣ 'ਤੇ ਵੀ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਨਾ ਖੁੱਲ੍ਹਣਾ ਡਿਵਾਈਸ ਪਹੁੰਚ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹਾ no such file ਦੀ ਬਜਾਏ permission denied ਕਹੇਗਾ। ਇਹਨਾਂ ਦੋ ਅਸਫਲਤਾਵਾਂ ਦਾ ਕ੍ਰਮ ਹੀ ਪੂਰਾ ਨਿਦਾਨ ਹੈ। ਕੋਈ ਫਲੈਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਦੇਖਿਆ।

TUN ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਗਲਤੀਆਂ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ

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

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

ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਇੰਟਰਫੇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set ਵਿੱਚ ਮੌਜੂਦ ਪਰ effective set ਵਿੱਚ ਗੈਰਹਾਜ਼ਰ ਸਮਰੱਥਾ ਕਦੇ ਨਾ ਦਿੱਤੀ ਗਈ ਸਮਰੱਥਾ ਨਾਲੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ, ਅਤੇ capsh ਦੋਵੇਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਨੋਡ ਮੌਜੂਦ ਹੈ ਅਤੇ ਸਮਰੱਥਾ ਵੀ ਹੈ ਪਰ ਬਣਾਉਣਾ ਅਜੇ ਵੀ ਅਸਫਲ ਹੈ, ਤਾਂ ਰਨਟਾਈਮ ਕੁਝ ਹੋਰ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ, ਜਿਵੇਂ ਕਿ seccomp ਪ੍ਰੋਫਾਈਲ ਜਾਂ AppArmor ਨੀਤੀ ਜੋ ਕਾਰਵਾਈ ਨੂੰ ਸੀਮਿਤ ਕਰਦੀ ਹੈ। ਇਹ ਤੀਜੀ ਸੀਮਾ ਹੈ, ਜਿਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਸਗੋਂ ਰਨਟਾਈਮ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ।

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