/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 ಹೊಂದಿರುವ ಅಕ್ಷರ ಸಾಧನವೇ, ಮೌಂಟ್ ಆಯ್ಕೆಗಳು ಸ್ವಚ್ಛವೇ, ಪ್ರಕ್ರಿಯೆ ಸಂದರ್ಭ ಸಾಮರ್ಥ್ಯ ಹೊಂದಿದೆಯೇ, ಮತ್ತು ವೈಫಲ್ಯದ ಸಮಯಮುದ್ರೆಯಲ್ಲಿ ನೀತಿ ನಿರಾಕರಣೆ ಇದೆಯೇ. ಐದನ್ನೂ ದಾಟಿ ಉಳಿಯುವ ದೋಷ ಸಾಧನದ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಸಂದೇಶ ಏನೇ ಹೇಳಿದರೂ.