/dev/net/tun ਗਾਇਬ ਹੈ ਜਦੋਂ ਕਿ tun ਲੋਡ ਹੈ: ਡਿਵਾਈਸ ਨੋਡ ਠੀਕ ਕਰੋ

OpenVPN errno 2 ਸ਼ਿਕਾਇਤ ਨਾਲ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਉਹ /dev/net/tun ਬਾਰੇ ਹੈ, ਜਦਕਿ lsmod tun ਮਾਡਿਊਲ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਤੱਥ ਇੱਕੋ ਸਮੇਂ ਸੱਚ ਹਨ। ਮਾਡਿਊਲ ਡਰਾਈਵਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਜੋ ਰਾਹ ਖੋਲ੍ਹਦਾ ਹੈ ਉਹ ਡਿਵਾਈਸ ਨੋਡ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਨੇ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਵਸਤੂ ਮੰਨਣਾ ਹੀ ਉਹ ਕਾਰਨ ਹੈ ਕਿ ਮਾਡਿਊਲ ਦੁਬਾਰਾ ਲੋਡ ਕਰਨ ਦਾ ਸਪੱਸ਼ਟ ਹੱਲ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲਦਾ।

ਦੋ ਵਸਤੂਆਂ, ਦੋ ਵੱਖਰੇ ਮਾਲਕ

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

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

lsmod | grep -w tun
stat -c "%F %t:%T" /dev/net/tun
grep " /dev " /proc/mounts

devtmpfs ਬਨਾਮ ਸਪੱਸ਼ਟ mknod

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

ਇਰਾਦਿਆਂ ਦੀ ਨਹੀਂ, ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ devtmpfs /dev ਉੱਤੇ ਮਾਊਂਟ ਹੈ ਅਤੇ ਨੋਡ ਅਜੇ ਵੀ ਗਾਇਬ ਹੈ, ਤਾਂ ਡਰਾਈਵਰ ਉਹ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਮੰਨ ਰਹੇ ਹੋ, ਜਾਂ ਕਿਸੇ ਨੇ ਬੂਟ ਤੋਂ ਬਾਅਦ ਨੋਡ ਹਟਾ ਦਿੱਤਾ। ਜੇ /dev ਖੋਲ੍ਹੀ ਗਈ rootfs ਦੇ ਅੰਦਰ ਇੱਕ ਆਮ ਡਾਇਰੈਕਟਰੀ ਹੈ, ਤਾਂ ਕੋਈ ਆਪਣੇ-ਆਪ ਮਕੈਨਿਜ਼ਮ ਨਹੀਂ ਹੈ ਅਤੇ ਇਮੇਜ ਬਣਾਉਣ ਵਾਲੇ ਨੂੰ ਨੋਡ ਬਣਾਉਣਾ ਪਵੇਗਾ।

stat -c "%F major=%t minor=%T" /dev/net/tun
# expect: character special file major=a minor=c8

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

sudo modprobe tun
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun
ls -l /dev/net/tun

ਸਭ ਤੋਂ ਤੇਜ਼ ਭੇਦਕ stat ਦੱਸਦਾ ਹੈ ਉਹ ਕਿਸਮ ਹੈ, ਅਤੇ ਉਸ ਰਾਹ ਉੱਤੇ ਡਾਇਰੈਕਟਰੀ ਹੋਣਾ ਘੱਟੋ-ਘੱਟ ਇਮੇਜਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਹੈਰਾਨੀ ਹੈ। ਚੰਗੀ ਨੀਅਤ ਨਾਲ ਲਿਖਿਆ mkdir Dockerfile ਵਿੱਚ ਠੀਕ ਉਹੀ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਿੰਨੇ ਵੀ ਮਾਡਿਊਲ ਲੋਡ ਕਰੋ, ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਅੱਖਰ ਯੰਤਰ ਨਾਲ ਨਹੀਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ। Major 10 ਅਤੇ minor 200 tun ਲਈ ਰਜਿਸਟਰ ਹੋਈ ਜੋੜੀ ਹੈ, ਜੋ ਹੈਕਸ ਵਿੱਚ a ਅਤੇ c8 ਵਜੋਂ ਦਰਸਾਈ ਜਾਂਦੀ ਹੈ।

ਚਾਰ ਨਿਸ਼ਾਨ, ਚਾਰ ਕਾਰਨ

ਚਾਰ ਕਾਰਨ ਲਗਭਗ ਹਰ ਮਾਮਲੇ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਲੌਗ ਵਿੱਚ ਵੱਖਰਾ ਨਿਸ਼ਾਨ ਛੱਡਦਾ ਹੈ। ਬੂਟ ਵਾਤਾਵਰਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਡਿਸਕ ਰਹਿਤ ਇਮੇਜ, ਐਂਬੈਡਿਡ ਬੋਰਡ ਅਤੇ initramfs ਪੜਾਅ ਅਕਸਰ ਨਾ ਤਾਂ devtmpfs ਅਤੇ ਨਾ ਹੀ udev ਦੁਆਰਾ ਸੰਭਾਲੀ /devਮਾਊਂਟ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਪ੍ਰਕਿਰਿਆ ਕਦੇ ਨੋਡ ਨਹੀਂ ਲਿਖਦੀ। ਫਿਰ /devਹੋਸਟ ਕਰਨ ਵਾਲੇ ਦੇ ਮਾਊਂਟ ਵਿਕਲਪ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ nodev ਰਾਹ ਨੂੰ ਮੌਜੂਦ ਰਹਿਣ ਦਿੰਦਾ ਹੈ ਪਰ ਖੋਲ੍ਹਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਖ਼ਤ ਕੀਤੇ ਹੋਸਟ ਤੋਂ ਲਿਆ bind ਮਾਊਂਟ ਆਪਣੀ ਘੋਸ਼ਣਾ ਕੀਤੇ ਬਿਨਾਂ ਇਹ ਝੰਡਾ ਚੁੱਕਦਾ ਹੈ। ਸਿਰਫ਼-ਪੜ੍ਹਨ ਮਾਊਂਟ ਪਹਿਲਾਂ ਅਤੇ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: mknod ਉੱਥੇ EROFS ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜਦਕਿ EPERM ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਸਮਰੱਥਾ ਨਹੀਂ, ਇਹ ਨਹੀਂ ਕਿ ਫਾਈਲ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਨੂੰ ਬਚਾ ਰਿਹਾ ਹੈ। ਅੰਤ ਵਿੱਚ, ਆਪਣੀ /dev tmpfs ਵਾਲੇ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਨੂੰ ਨੋਡ ਆਪਣੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸੁੱਟਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਉਸਦੇ ਡਿਵਾਈਸ cgroup ਨੂੰ major ਅਤੇ minor ਜੋੜੀ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਪੈਂਦੀ ਹੈ।

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

sudo journalctl -k -n 20 --no-pager
sudo ausearch -m AVC -ts recent | tail -5

ਇਸਨੂੰ ਇੰਟਰਫੇਸ ਨਾਲ ਸਾਬਤ ਕਰੋ, ਸੂਚੀ ਨਾਲ ਨਹੀਂ

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

head -c 1 /dev/net/tun
head: error reading '/dev/net/tun': File descriptor in bad state

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

sudo ip tuntap add dev tun7 mode tun
ip -brief link show tun7
sudo ip tuntap del dev tun7 mode tun

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

ਜਦੋਂ ਯੰਤਰ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ

ਜੇ ਇੰਟਰਫੇਸ ਪਰੀਖਿਆ ਸਫਲ ਹੋਵੇ ਅਤੇ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਬਚੀ ਸਮੱਸਿਆ ਪਰੋਫਾਈਲ, ਸੇਵਾ ਸੰਦਰਭ ਜਾਂ ਰਸਤਾ ਹੈ, ਅਤੇ ਯੰਤਰ ਠੀਕ ਹੈ। ਉਹੀ ਡਿਵਾਈਸ ਨੋਡ ਸੰਪਾਦਿਤ ਕਰਨਾ ਬੰਦ ਕਰਨ ਦਾ ਪਲ ਹੈ, ਕਿਉਂਕਿ ਹੋਰ ਤਬਦੀਲੀਆਂ ਕੰਮ ਕਰ ਰਹੇ ਸਿਸਟਮ ਤੋਂ ਦੂਰੀ ਹੀ ਵਧਾਉਂਦੀਆਂ ਹਨ।

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