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 ನೀತಿಯಂತಹ ಬೇರೆ ಯಾವುದನ್ನೋ ಜಾರಿಗೊಳಿಸುತ್ತಿದೆ. ಅದು ಮೂರನೇ ಗಡಿ, ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲ ರನ್ಟೈಮ್ ದಾಖಲಿಸುವುದು.

ಕಂಟೇನರ್ ಫ್ಲ್ಯಾಗ್ಗಳು, ಇಮೇಜ್ ಮತ್ತು ಪ್ರತಿ ಪ್ರಯತ್ನದ ನಿಖರ ದೋಷವನ್ನು ದಾಖಲಿಸಿ. ಆ ಟಿಪ್ಪಣಿಯನ್ನು ಓದುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಇಡೀ ತನಿಖೆಯನ್ನು ಪುನರಾವರ್ತಿಸದೆ ಯಾವ ಬಾಗಿಲು ಮುಚ್ಚಿತ್ತು ಎಂದು ಹೇಳಬಲ್ಲ.