ನಿಮ್ಮ VPN ಪ್ರಕ್ರಿಯೆಗೆ ಯಾವ Linux ಸಾಮರ್ಥ್ಯಗಳು ಬೇಕು?
ಇಂಟರ್ಫೇಸ್ ಸೆಟಪ್, ರೂಟ್ಗಳು, ಸಾಧನ ಪ್ರವೇಶ ಮತ್ತು ಸಾಮಾನ್ಯ ಸಾಕೆಟ್ಗಳು ಪ್ರತ್ಯೇಕ ಸವಲತ್ತುಗಳು. CAP_NET_ADMIN ನೀಡುವ ಮೊದಲು ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಸರಿಸಿ.
VPN ಡೀಮನ್ಗೆ ವಿಶೇಷ ಸವಲತ್ತಿನ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಬೇಕು, ಆದರೂ ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಯಾವುದೇ ಸವಲತ್ತಿಲ್ಲದೆ ಹೊರಹೋಗುವ ಸಾಕೆಟ್ಗಳನ್ನು ತೆರೆಯುತ್ತವೆ. ಅದೇ ಅಂತರದಿಂದಲೇ ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯ ದೋಷಗಳು ಆರಂಭವಾಗುತ್ತವೆ: ಯಾರೋ ಅನುಮತಿ ದೋಷವನ್ನು ನೋಡಿ ಇಡೀ ಸೆಟ್ ಅನ್ನು ನೀಡುತ್ತಾರೆ, ಮತ್ತು ಸೇವೆ ನಂತರ ಯಾರೂ ವಿವರಿಸಲಾಗದ ಕಾರಣಗಳಿಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಕೆಳಗಿನ ವಿವರಣೆ ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಆರಂಭವಾಗುತ್ತದೆ, ಅದನ್ನು ಒಂದು ಅಧಿಕಾರಕ್ಕೆ ಜೋಡಿಸುತ್ತದೆ, ನಂತರ ಪ್ರಕ್ರಿಯೆ ನಿಜವಾಗಿ ಚಲಿಸುವ ಸಂದರ್ಭವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅನಿಯಮಿತ root ಆಗಿ ಚಲಿಸುವುದು ಕೆಲವು ನಿಯೋಜನೆಗಳಿಗೆ ಮಾನ್ಯ ಉತ್ತರ, ಆದರೆ ಅದು ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ, ನಿರ್ಧಾರವಾಗಿರಬೇಕು.
ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಆರಂಭಿಸಿ
ಟ್ಯುಟೋರಿಯಲ್ ಓದುವ ಮೊದಲು ದೋಷವನ್ನು ಓದಿ. ಇಂಟರ್ಫೇಸ್ ಬದಲಾವಣೆಯಲ್ಲಿ «ಕಾರ್ಯಾಚರಣೆಗೆ ಅನುಮತಿ ಇಲ್ಲ», ಸಾಧನ ನೋಡ್ ತೆರೆಯಲು ನಿರಾಕರಣೆ ಮತ್ತು ಕಡಿಮೆ ಪೋರ್ಟ್ನಲ್ಲಿ ಬೈಂಡ್ ವೈಫಲ್ಯ — ಇವು ಮೂರು ಬೇರೆ ಸಮಸ್ಯೆಗಳು, ಮೂರು ಬೇರೆ ಅನುಮತಿಗಳೊಂದಿಗೆ. ಪ್ರಕ್ರಿಯೆ ಆರಂಭವಾಗಿ ಮೊದಲ ರೂಟ್ ಬದಲಾವಣೆಯಲ್ಲಿ ಮಾತ್ರ ವಿಫಲವಾದರೆ, ಅದು ಇಂಟರ್ಫೇಸ್ ರಚನೆ ಈಗಾಗಲೇ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದೂ ಹೇಳುತ್ತದೆ, ಇದು ಉತ್ತರವನ್ನು ಬಹಳ ಕಿರಿದಾಗಿಸುತ್ತದೆ.
ಸೇವೆ ನಿಲ್ಲಿಸಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ವೈಫಲ್ಯವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಅನುಷ್ಠಾನ ಅನುಮತಿಸಿದರೆ ಅದನ್ನು ಅದೇ ಬಳಕೆದಾರರಡಿಯಲ್ಲಿ ಮುಂಭಾಗದಲ್ಲಿ ಆರಂಭಿಸಿ. ನೀವು ನೋಡಬಹುದಾದ ದೋಷವು ಊಹಿಸಬೇಕಾದ ಲಾಗ್ ಸಾಲಿಗಿಂತ ಉತ್ತಮ, ಮತ್ತು ಅದು ಸಾಮರ್ಥ್ಯ ಸಮಸ್ಯೆ ಹಾಗೂ SELinux ಅಥವಾ AppArmor ನಿರಾಕರಣೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
ಪ್ರತಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಒಂದು ಅಧಿಕಾರಕ್ಕೆ ಜೋಡಿಸಿ
ಕೋಷ್ಟಕ ಆರಂಭಿಕ ನಕ್ಷೆ, ಅನುಷ್ಠಾನದ ದಾಖಲೆಗೆ ಪರ್ಯಾಯವಲ್ಲ:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
ಆ ಕೋಷ್ಟಕದ ಎರಡು ಸಾಲುಗಳೇ ಜನರು ಗೊಂದಲಪಡುವ ಸಾಲುಗಳು. /dev/net/tun ತೆರೆಯುವುದು ಫೈಲ್ ಅನುಮತಿಯ ಪ್ರಶ್ನೆ; ನೀವು ತೆರೆದದ್ದನ್ನು ಸಂರಚಿಸಲು ಕರ್ನಲ್ಗೆ ಕೇಳುವುದು ಸಾಮರ್ಥ್ಯದ ಪ್ರಶ್ನೆ. CAP_NET_ADMIN ನೀಡುವುದು ನಿಮ್ಮ ಸೇವಾ ಬಳಕೆದಾರರು ಓದಲಾಗದ ಸಾಧನ ನೋಡ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ನೋಡ್ ಸರಿಪಡಿಸುವುದು ನಿಮಗೆ ರೂಟ್ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಬದಲಾಯಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ.
ಕರ್ನಲ್ನ WireGuard ಮತ್ತು ಬಳಕೆದಾರ ಸ್ಥಳದ ಟನಲ್ ಪ್ರೋಗ್ರಾಮ್ಗಳ ಅಗತ್ಯಗಳೂ ಒಂದೇ ಅಲ್ಲ. ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಮಾರ್ಗವು ಇರುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು netlink ಮೂಲಕ ಸಂರಚಿಸುತ್ತದೆ, ಆದರೆ ಬಳಕೆದಾರ ಸ್ಥಳದ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಾಧನವೂ ಬೇಕಾಗಬಹುದು ಮತ್ತು ಕೆಲವು ಸಾಗಣೆಗಳಿಗೆ ಕಚ್ಚಾ ಸಾಕೆಟ್ಗಳೂ ಬೇಕಾಗಬಹುದು.
ಸಂದರ್ಭವನ್ನು ಓದಿ: ಸೇವೆ, ಕಂಟೇನರ್ ಅಥವಾ ಶೆಲ್
ಹೋಸ್ಟ್ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿನ ಸಾಮರ್ಥ್ಯವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿದ ಸ್ಟಾಕ್ನಲ್ಲಿನ ಅದೇ ಕಾರ್ಯಾಚರಣೆಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರಬಹುದು. ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಿದ ಗಡಿ ಸೆಟ್ನೊಂದಿಗೆ ಆರಂಭವಾಗುತ್ತದೆ; ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕ್ ಹಂಚಿಕೊಳ್ಳುವ ಕಂಟೇನರ್ಗೆ NET_ADMIN ಸೇರಿಸುವುದು ತನ್ನದೇ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಮತ್ತು ಹೋಸ್ಟ್ ಮೌಂಟ್ಗಳಿಲ್ಲದ ಕಂಟೇನರ್ಗೆ ಸೇರಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡ ಅನುಮತಿ.
systemd ಘಟಕಗಳಿಗೆ ಘಟಕ ಫೈಲ್ ಹೇಳುತ್ತದೆ ಎಂದು ಕಾಣುವುದಲ್ಲ, ನಿಜವಾಗಿ ಅನ್ವಯವಾಗುವುದನ್ನು ಓದಿ: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಅವು ನೀವು ಮರೆತ drop-in ನಿಂದ ಸೆಟ್ ಆಗಿರಬಹುದು. ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯವನ್ನು ಕೇಳಿ, ಎಂದಿಗೂ ಉದ್ದೇಶಿತದ್ದನ್ನು ಅಲ್ಲ. Ambient ಸಾಮರ್ಥ್ಯಗಳು ಮುಖ್ಯ, ಏಕೆಂದರೆ root ಅಲ್ಲದ ಸೇವೆ ಅವುಗಳಿಲ್ಲದೆ exec ಉದ್ದಕ್ಕೂ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
ಪ್ಯಾಕೇಜ್ ಅಥವಾ ಇಮೇಜ್ನ ಬೆಂಬಲಿತ ಸೆಟಪ್ ಅನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಿ. ಬೇರೆ ಟ್ಯುಟೋರಿಯಲ್ ಬೇರೆ ಸಾಧನಕ್ಕೆ ಅವನ್ನು ಪಟ್ಟಿ ಮಾಡಿದೆ ಎಂದು ಕಚ್ಚಾ ಸಾಕೆಟ್ ಅನುಮತಿಗಳನ್ನು ಅಥವಾ ವಿಶೇಷ ಸವಲತ್ತಿನ ಮೋಡ್ ಸೇರಿಸಬೇಡಿ; ಆ ತರ್ಕ ಏನನ್ನೂ ವರ್ಗಾಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ನೀವು ಪಾವತಿಸಿದ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಂದೇಹವಿದ್ದರೆ ಏನನ್ನೂ ನೀಡಬೇಡಿ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ನಿಖರ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಅನುಷ್ಠಾನದ ಟಿಪ್ಪಣಿಗಳನ್ನು ಓದಿ.
ಸವಲತ್ತುಗಳು ಇಳಿದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ
ಅನೇಕ ಡೀಮನ್ಗಳು ಸವಲತ್ತಿನೊಂದಿಗೆ ಆರಂಭವಾಗಿ, ಇಂಟರ್ಫೇಸ್ ಸಂರಚಿಸಿ, ನಂತರ ಸವಲತ್ತಿಲ್ಲದ ಬಳಕೆದಾರರಿಗೆ ಇಳಿದು ಟನಲ್ ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಆ ಕ್ಷಣದಿಂದ ಪ್ರಕ್ರಿಯೆ ಇನ್ನು ರೂಟ್ ಸೇರಿಸಲಾಗದು, ಫೈರ್ವಾಲ್ ನಿಯಮವನ್ನು ಮರುಬರೆಯಲಾಗದು ಅಥವಾ ಹೊಸ ಸವಲತ್ತಿನ ಸಾಧನ ತೆರೆಯಲಾಗದು, ಮತ್ತೆ ಸಂಪರ್ಕಕ್ಕೆ ನಿಖರವಾಗಿ ಅದೇ ಬೇಕಾಗುವವರೆಗೆ ಇದು ಸರಿ. ನಂತರದ ಫೈಲ್ ಓದುವಿಕೆ ಮತ್ತು ಹುಕ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಅದೇ ಕಾರಣಕ್ಕೆ ವಿಫಲವಾಗಬಹುದು.
ಮೊದಲ ಸೆಕೆಂಡ್ ಅಲ್ಲ, ಇಡೀ ಜೀವನಚಕ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ: ಆರಂಭ, ನವೀಕರಣ ಅಥವಾ ಮರುಸಂಪರ್ಕ, ಮತ್ತು ನಿಲ್ಲಿಸುವಾಗ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ. ಇಂಟರ್ಫೇಸ್ ಮೊದಲ ಬಾರಿ ಯಶಸ್ವಿಯಾಗಿ ರಚನೆಯಾಗುವುದು ಮುಂದಿನ ಪ್ರತಿ ಸವಲತ್ತಿನ ಕಾರ್ಯಾಚರಣೆಯೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ವೈಫಲ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಗಂಟೆಗಳ ನಂತರ ಕಾಣಿಸುತ್ತದೆ.
ಬಳಕೆದಾರ ಬದಲಾವಣೆಯ ಉದ್ದಕ್ಕೂ ಟನಲ್ ತೆರೆದಿಡುವ ಅನುಷ್ಠಾನಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ಟನಲ್ ಮತ್ತು ಕೀಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಆಯ್ಕೆಗಳೊಂದಿಗೆ ಜೋಡಿಸುತ್ತವೆ. systemd ಕಡೆಗೆ ಸಮಾನ ಪ್ರಶ್ನೆ ಎಂದರೆ ಘಟಕದ ಸಾಮರ್ಥ್ಯ ಸೆಟ್ ನೀವು ಸಂರಚಿಸಿದ ಬಳಕೆದಾರ ಬದಲಾವಣೆಯನ್ನು ಎದುರಿಸುತ್ತದೆಯೇ ಎಂಬುದು.
ನೀಡಿದ ಅನುಮತಿ ಮತ್ತು ಅದರ ಕಾರಣವನ್ನು ದಾಖಲಿಸಿ
ನಿಖರ ಅನುಮತಿ, ಅದು ಸಾಧ್ಯವಾಗಿಸುವ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಅದು ಸರಿಪಡಿಸಿದ ದೋಷವನ್ನು ಬರೆಯಿರಿ. ನಿಯೋಜನಾ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಒಂದು ಸಾಲು — «ಘಟಕದ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ CAP_NET_ADMIN, ಮರುಸಂಪರ್ಕದ ನಂತರ ರೂಟ್ ಬದಲಾವಣೆಗಳಿಗೆ ಅಗತ್ಯ» — ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅನುಮತಿಯನ್ನು ಮತ್ತೆ ವಿಸ್ತರಿಸದಂತೆ ತಡೆಯಲು ಸಾಕು.
ನಂತರ ಪ್ರತಿ ಅಪ್ಗ್ರೇಡ್ ನಂತರ ಪರಿಣಾಮಕಾರಿ ಸೆಟ್ ಅನ್ನು ಮತ್ತೆ ಓದಿ. ಮಾರಾಟಗಾರರು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ, ಇಮೇಜ್ಗಳು ಡೀಫಾಲ್ಟ್ ಬದಲಾಯಿಸುತ್ತವೆ, ಮತ್ತು ಕಳೆದ ವರ್ಷ ಅನಗತ್ಯವಾಗಿದ್ದ ಸಾಮರ್ಥ್ಯ ಯಾರಿಗೂ ಗೊತ್ತಾಗದೆ ಭಾರವಾಹಕವಾಗಬಹುದು.