VPN ಗೆ ಅಗತ್ಯವಿರುವುದಕ್ಕಿಂತ ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಮೋಡ್ ಏಕೆ ವಿಶಾಲವಾಗಿದೆ

ಕಂಟೇನರ್ ತನ್ನ ಸುರಂಗವನ್ನು ತೆರೆಯುತ್ತಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಧ್ವಜ ಸೇರಿಸಲಾಯಿತು, ಮತ್ತು ಈಗ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆ ಅನುಕ್ರಮವು ಕನಿಷ್ಠ ಒಂದು ಅನುಮತಿ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸಿತು, ಮತ್ತು ಯಾವುದು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಮೋಡ್ ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬೇಕಾದುದಕ್ಕಿಂತ ಬಹಳ ವಿಶಾಲವಾದ ಸಾಮರ್ಥ್ಯಗಳ ಗುಂಪು ಮತ್ತು ಸಾಧನ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ.

ಧ್ವಜವು ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ

ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಕಂಟೇನರ್ ವಿಶಾಲ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ಹೋಸ್ಟ್ ಸಾಧನಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುತ್ತದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಮಾರ್ಗಕ್ಕೆ ಬೇಕಾದುದಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡ ಅನುಮತಿಯಾಗಿದೆ. ನಿಖರವಾದ ಗುಂಪನ್ನು ಜನಪದ ಕಥೆಗಳಲ್ಲ, ರನ್‌ಟೈಮ್ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು Docker ನ ಕಂಟೇನರ್ ಚಲಾಯಿಸುವ ದಾಖಲೆಗಳು ಲಭ್ಯವಿರುವ ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಒಮ್ಮೆ ಓದಿದರೆ ಸುರಂಗವು ಒಟ್ಟಿನ ಸಣ್ಣ ಭಾಗ ಎಂದು ನೋಡಲು ಸಾಕು.

ಎರಡು ಸಂಕುಚಿತ ಅಗತ್ಯಗಳು ಬಹುಪಾಲು VPN ಕಂಟೇನರ್‌ಗಳನ್ನು ಆವರಿಸುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ ಸಂರಚಿಸಲು ನೆಟ್‌ವರ್ಕ್ ಆಡಳಿತ ಸಾಮರ್ಥ್ಯ ಬೇಕು, ಮತ್ತು ಸುರಂಗ ಸಾಧನ ತೆರೆಯಲು ಆ ನಿರ್ದಿಷ್ಟ ಸಾಧನ ನೋಡ್‌ಗೆ ಪ್ರವೇಶ ಬೇಕು. ಇವು ಪ್ರತ್ಯೇಕ ಅನುಮತಿಗಳು, ಮತ್ತು ಎರಡನ್ನೂ ನೀಡಿದರೂ ಅದು ಸರ್ವವ್ಯಾಪಿ ಆಯ್ಕೆಗಿಂತ ಸಂಕುಚಿತವಾಗಿಯೇ ಇರುತ್ತದೆ. ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಗುಂಪಿನ ಉಳಿದ ಭಾಗಕ್ಕೆ ಸುರಂಗದೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಇದು ನಿಜವಾಗಿ ಹೋಸ್ಟ್ ಮಟ್ಟದ ಪ್ರವೇಶ ಬೇಕಾದ ಕೆಲಸಗಳಿಗೆ ಇದೆ, ಮತ್ತು VPN ಕಂಟೇನರ್ ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದಲ್ಲ.

ಪ್ರತಿ ದೋಷವನ್ನು ಒಂದು ಪೂರ್ವಷರತ್ತಿಗೆ ಹೊಂದಿಸಿ

ದೋಷ ಸಂದೇಶವನ್ನು ಅಡಗಿಸುವ ಮೊದಲು ಓದಿದರೆ ಯಾವ ಪೂರ್ವಷರತ್ತು ಕಾಣೆಯಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಸಾಧನ ನೋಡ್ ಬಗ್ಗೆ ಸಂದೇಶ ಸಾಧನವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಅನುಮತಿಸದ ಕಾರ್ಯಾಚರಣೆ ಬಗ್ಗೆ ಸಂದೇಶ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಅಥವಾ sysctl ಬಗ್ಗೆ ಸಂದೇಶ ಕರ್ನಲ್ ಬೆಂಬಲವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಪರಿಹಾರವಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸಾಮರ್ಥ್ಯ.

ಕಾಣೆಯಾದ ಸಂರಚನಾ ಫೈಲ್ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡಿದ ನಂತರವೂ ಕಾಣೆಯಾಗಿಯೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಮೋಡ್ ಕೆಲವೊಮ್ಮೆ ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಕಂಟೇನರ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಸುರಂಗ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ನಿಜವಾದ ದೋಷ ಎಂದೂ ಅನುಮತಿಗಳ ಬಗ್ಗೆ ಇರಲಿಲ್ಲ. ಕರ್ನಲ್ ಬೆಂಬಲವು ಮೂರನೇ ಸಂದರ್ಭ ಮತ್ತು ತಪ್ಪಾಗಿ ಓದಲು ಅತ್ಯಂತ ಸುಲಭ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಲೋಡ್ ಆಗದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ವಿಶೇಷ ಸ್ಥಾನಮಾನವಿಲ್ಲದ ಕಂಟೇನರ್ ಒಳಗಿನಿಂದ ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಕಂಟೇನರ್ ಒಳಗೆ ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯ ನೀಡುವುದು ಹೋಸ್ಟ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ.

ಲಕ್ಷಣವಲ್ಲ, ಅಗತ್ಯವನ್ನು ಪರಿಶೀಲಿಸಿ

ಇಮೇಜ್ ದಾಖಲಿಸುವ ಕನಿಷ್ಠ ಕರೆನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅದನ್ನು ಚಲಾಯಿಸಿ, ಮತ್ತು ವಿಫಲತೆಯ ನಿಖರ ಪಠ್ಯವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ನಂತರ ಒಂದೊಂದಾಗಿ ಅನುಮತಿ ಸೇರಿಸಿ ಮತ್ತು ಯಾವ ಸೇರ್ಪಡೆ ಫಲಿತಾಂಶವನ್ನು ಬದಲಾಯಿಸಿತು ಎಂದು ಗಮನಿಸಿ.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

ಸಾಧನವನ್ನು ನೋಡಬಲ್ಲ ಮತ್ತು ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಆದರೆ ಇನ್ನೂ ವಿಫಲವಾಗುವ ಕಂಟೇನರ್ ಸಮಸ್ಯೆ ಬೇರೆಡೆ ಇದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅದು ಉಪಯುಕ್ತ ಫಲಿತಾಂಶ, ಮತ್ತು ವಿಶೇಷ ಸ್ಥಾನಮಾನದ ಮೋಡ್ ಅದನ್ನು ಮರೆಮಾಡುತ್ತಿತ್ತು.

ಹೋಸ್ಟ್‌ನಲ್ಲಿಯೂ ಸಾಧನ ಅನುಮತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸರಿಯಾಗಿ ನೀಡಲಾದ ಸಾಧನ ನೋಡ್ ತಪ್ಪು ಗುಂಪು ಮಾಲೀಕತ್ವದೊಂದಿಗೆ ಕಾಣೆಯಾದ ಅನುಮತಿಯಂತೆಯೇ ಅದೇ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಕೆಲಸ ಮಾಡುವ ಅತ್ಯಂತ ಸಂಕುಚಿತ ಅನುಮತಿಯನ್ನು ದಾಖಲಿಸಿ

ನಿಯೋಜನೆಗೆ ಬೇಕಾದ ಪ್ರತಿ ಸಾಧನ ಮತ್ತು ಸಾಮರ್ಥ್ಯವನ್ನು ಅವುಗಳನ್ನು ಸಮರ್ಥಿಸಿದ ದೋಷದೊಂದಿಗೆ ಬರೆಯಿರಿ. ಆ ದಾಖಲೆಯೇ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಏನನ್ನಾದರೂ ಸುರಕ್ಷಿತವಾಗಿ ತೆಗೆದುಹಾಕಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ ವಿಶೇಷ ಸ್ಥಾನಮಾನದ್ದು ಎಂದು ವರದಿಯಾದಾಗ ಲೆಕ್ಕಪರಿಶೋಧಕರು ಕೇಳುವುದೂ ಅದನ್ನೇ.

ಸುತ್ತಮುತ್ತಲಿನ ಸಂದರ್ಭವನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹೋಸ್ಟ್ ನೆಟ್‌ವರ್ಕಿಂಗ್, ಹೋಸ್ಟ್ ಮೌಂಟ್‌ಗಳು ಮತ್ತು ರನ್‌ಟೈಮ್ ಆಯ್ಕೆಗಳು ಪ್ರತಿಯೊಂದೂ ಅನುಮತಿಯ ಪ್ರಭಾವವನ್ನು ವಿಸ್ತರಿಸಬಹುದು. ಎಲ್ಲವನ್ನೂ ಸಂಯೋಜಿಸುವ ಪ್ರತ್ಯೇಕ ಲ್ಯಾಬ್ ಕರೆ, ಅದು ಎಷ್ಟೇ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದರೂ, ಉತ್ಪಾದನಾ ಸಂರಚನೆ ಅಲ್ಲ. ನಿಯೋಜನೆಯನ್ನು ಪೂರ್ಣ ಎಂದು ಕರೆಯುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್, ಅದರ DNS ವರ್ತನೆ ಮತ್ತು ಸುರಂಗ ವಿಫಲತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಇಂಟರ್ಫೇಸ್ ರಚಿಸುವ ಅನುಮತಿ ನಿರ್ಗಮನ ನೀತಿ ಅಲ್ಲ, ಮತ್ತು ಪರಿಪೂರ್ಣವಾಗಿ ಸುರಂಗ ಮಾಡಬಲ್ಲ ಕಂಟೇನರ್ ಇನ್ನೂ ಅಪ್ಲಿಕೇಶನ್ ಕಳುಹಿಸುವ ಎಲ್ಲವನ್ನೂ ಮಾರ್ಗೀಕರಿಸುತ್ತದೆ.