ನಿಮ್ಮ OpenVPN ಹುಕ್ ಅನ್ನು ಯಾವ systemd ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ನಿರಾಕರಿಸಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ

ನೀವು ಅದನ್ನು root ಆಗಿ ಕೈಯಿಂದ ಚಲಾಯಿಸಿದಾಗ ಹುಕ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹಿಂತಿರುಗಿಸುತ್ತದೆ Operation not permitted ಸೇವೆ ಅದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಕ್ಷಣದಲ್ಲಿ. ಆ ಎರಡು ಚಲಾವಣೆಗಳ ನಡುವೆ ಫೈಲ್ ಬದಲಾಗಲಿಲ್ಲ; ಪರಿಸರ ಬದಲಾಯಿತು. systemd ಪ್ರಕ್ರಿಯೆಗೆ ಚಿಕ್ಕ ಜಗತ್ತನ್ನು ಕೊಡುತ್ತದೆ: ಕಡಿಮೆ ಸಾಮರ್ಥ್ಯಗಳು, ಬೇರೆ /dev, ಓದಲು-ಮಾತ್ರ ಫೈಲ್‌ಸಿಸ್ಟಂ ಮಾರ್ಗಗಳು ಮತ್ತು ಕಾರ್ಯಗಳ ಮೇಲಿನ ಮಿತಿ. ವೈಫಲ್ಯವನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರಾಕರಿಸಿದ ಗಡಿ ಎಂದು ಓದಿ, ಮುರಿದ ಸ್ಕ್ರಿಪ್ಟ್ ಎಂದಲ್ಲ.

ನಿರಾಕರಿಸಲಾದ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ

unit ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುವ ಲಾಗ್ ಸಾಲು ನಿಮಗೆ ಬಹುತೇಕ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಉಪಯುಕ್ತ ಸಾಲು ನಿರಾಕರಿಸಲಾದ ಕರೆಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ: ತೆರೆಯಲಾಗದ ಸಾಧನ ನೋಡ್, ಬರೆಯಲಾಗದ ಡೈರೆಕ್ಟರಿ, ರಚಿಸಲಾಗದ namespace. ಒಂದೇ ನಿರ್ದೇಶನವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ಕರೆಯನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ನಿರ್ಬಂಧಕ್ಕೆ ಸರಿಹೊಂದುತ್ತದೆ. ನಂತರ ಪ್ಯಾಕೇಜ್ ಕಳುಹಿಸಿದ ಫೈಲ್ ಬದಲು ನಿಜವಾಗಿ ಚಲಿಸಿದ unit ಅನ್ನು ಓದಿ, drop-in ಸಹಿತ.

ಕೆಳಗಿನ ಪ್ರಶ್ನೆ ಫ್ರ್ಯಾಗ್ಮೆಂಟ್ ಮಾರ್ಗ, drop-in ಡೈರೆಕ್ಟರಿಗಳು ಮತ್ತು ಸಾಧನ ಅಥವಾ ಫೈಲ್‌ಸಿಸ್ಟಂ ನಿರಾಕರಣೆಗೆ ಮುಖ್ಯವಾದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಯಾವ ಗಡಿ ಸಂಬಂಧಿತ ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಎಲ್ಲವನ್ನೂ ಓದಿ:

systemctl show "[email protected]" -p FragmentPath -p DropInPaths -p PrivateDevices -p DevicePolicy -p DeviceAllow -p ProtectHome -p ProtectSystem -p TasksMax
journalctl -u "[email protected]" -b --no-pager | grep -iE 'operation not permitted|permission denied|cannot open|failed'

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

namespace ಗೆ TUN ಸಾಧನ ಎಂದೂ ಬಳಸದ mount ಹಕ್ಕುಗಳು ಬೇಕು

ಒಂದೇ ಹುಕ್ ಒಳಗೆ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಬೇರೆ ಅನುಮತಿ ಪ್ರೊಫೈಲ್‌ಗಳಿವೆ. /dev/net/tun ತೆರೆಯಲು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ರಚಿಸಲು ನೆಟ್‌ವರ್ಕ್ ಆಡಳಿತ ಮತ್ತು ಆ ನೋಡ್‌ಗೆ ಪ್ರವೇಶ ಬೇಕು. ಹೆಸರಿಸಿದ ನೆಟ್‌ವರ್ಕ್ namespace ರಚಿಸಲು ಸಹ mount ಕೆಲಸ ಬೇಕು, ಏಕೆಂದರೆ namespace ಸಾಧನ ಹೊಸ /sys ನೋಟವನ್ನು mount ಮಾಡಿ ಸ್ಥಿತಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ಅದರ ಜಾಗದಲ್ಲಿ ಬಿಗಿಯುತ್ತದೆ. ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಕ್ಲೈಂಟ್ unit ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ mount ಆಡಳಿತವನ್ನು ತನ್ನ ಗಡಿ ಗುಂಪಿನ ಹೊರಗೆ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ namespace ಹಂತ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ, ಆದರೆ ಸುರಂಗ ಸ್ವತಃ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು.

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

ನಿಮ್ಮ shell ನಲ್ಲಿನ ಪರೀಕ್ಷೆ ಮಿತಿಯಿಲ್ಲದ root ಹೊಂದಿರುವ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಮತ್ತು unit ತನ್ನ ಗಡಿ ಗುಂಪು ಉಳಿಸಿದ್ದನ್ನು ಪಡೆಯುತ್ತದೆ. ಆ ಎರಡು ಚಲಾವಣೆಗಳು ಬೇರೆ ಪ್ರಯೋಗಗಳು ಬೈನರಿ ಒಂದೇ ಆಗಿದ್ದರೂ.

ಸಾಧನಗಳು, ಸಂರಕ್ಷಿತ ಮಾರ್ಗಗಳು ಮತ್ತು ಕಾರ್ಯ ಮಿತಿಗಳು

ನಿರಾಕರಿಸಲಾದ ಕಾರ್ಯಾಚರಣೆ ತಿಳಿದ ನಂತರ, ಮೂರು ನಿರ್ದೇಶನ ಗುಂಪುಗಳು ಬಹುತೇಕ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಸಾಧನಗಳ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ PrivateDevices, ಅದು /dev ಅನ್ನು ಕನಿಷ್ಠ ಸ್ಯೂಡೋ-ಸಾಧನ ಗುಂಪಿನಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು DevicePolicy ಜೊತೆ DeviceAllow, ಅವು cgroup ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. /dev/net/tun ಆ ಕನಿಷ್ಠ ಗುಂಪಿನ ಭಾಗವಲ್ಲ, ಆದ್ದರಿಂದ PrivateDevices=yes ಇರುವ unit ಸಾಧನ ನೀತಿ ಏನೇ ಹೇಳಿದರೂ ಅದನ್ನು ತೆರೆಯಲಾರದು.

ಫೈಲ್‌ಸಿಸ್ಟಂ ರಕ್ಷಣೆ ಎರಡನೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ProtectHome=yes ಮಾಡುತ್ತದೆ /home, /root ಮತ್ತು /run/user ಅನ್ನು ತಲುಪಲಾಗದಂತೆ, ಮತ್ತು ProtectSystem=full ಮಾಡುತ್ತದೆ /usr, /boot ಮತ್ತು /etc ಅನ್ನು ಓದಲು-ಮಾತ್ರವಾಗಿ. ಆದ್ದರಿಂದ ತನ್ನ ಸ್ವಂತ ಸಂರಚನಾ ಫೈಲ್ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯುವ ಹುಕ್ ನಿಮ್ಮ shell ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು unit ಅಡಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಕಾಣೆಯಾದ ಸಾಮರ್ಥ್ಯದಂತೆಯೇ ಅದೇ ಅನುಮತಿ ಆಕಾರದೊಂದಿಗೆ. ಬರೆಯಬಹುದಾದ ಇನ್‌ಪುಟ್ ಅನ್ನು ನೀತಿ ಅನುಮತಿಸುವ ಮಾರ್ಗಕ್ಕೆ ಸರಿಸಿ, ಅಥವಾ ಕಿರಿದಾದ ReadWritePaths= ನಮೂದನ್ನು ಸೇರಿಸಿ.

ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು ಮೂರನೇ ಗುಂಪು, ಮತ್ತು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಲ್ಲದ್ದು. TasksMax= unit ಎಷ್ಟು ಕಾರ್ಯಗಳನ್ನು ರಚಿಸಬಹುದು ಎಂದು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಫೈಲ್-ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮಿತಿ ಸಾಕೆಟ್ ಮತ್ತು ಹ್ಯಾಂಡಲ್‌ಗಳಿಗೆ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ. ಮಿತಿ ಮೀರಿ ಬೆಳೆದ ನಿಯೋಜನೆ ಅನುಮತಿ ದೋಷದ ಬದಲು ಸಂಪನ್ಮೂಲ ದೋಷದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಖರ ಸಂದೇಶ ಇನ್ನೂ ಮುಖ್ಯ.

namespace ಹಂತವನ್ನು ಹುಕ್‌ನಿಂದ ಹೊರತೆಗೆಯಿರಿ

ಕ್ಲೈಂಟ್ ಹೊಂದಿರಬಾರದ ವಿಶೇಷಾಧಿಕಾರ ಬೇಕಾಗುವ ತಯಾರಿ ಅದರ ಸ್ವಂತ unit ಗೆ ಸೇರುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ಗಿಂತ ಮೊದಲು ಚಲಿಸುವ, ತನ್ನ ಫಲಿತಾಂಶವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಮತ್ತು ಸಂಪರ್ಕಕ್ಕಿಂತ ಮೊದಲು ಕ್ರಮಗೊಳಿಸಿದ oneshot namespace ಹಂತಕ್ಕೆ ಬೇಕಾದದ್ದನ್ನು ಕೊಡುತ್ತದೆ, ಆ ಹಕ್ಕುಗಳನ್ನು ಸುರಂಗ ಪ್ರಕ್ರಿಯೆಗೆ ಒಪ್ಪಿಸದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ತನ್ನ up ಹುಕ್‌ನಿಂದ ಸ್ಕ್ರಿಪ್ಟ್ ಕರೆಯುವ ಬದಲು ಆ unit ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ಟೆಂಪ್ಲೇಟ್ ಆರಂಭಿಕ ಆಕಾರ, ಓದದೆ ಅನ್ವಯಿಸುವಂತಹದ್ದಲ್ಲ. ಅದು ತಯಾರಿಯನ್ನು ವಿಶೇಷಾಧಿಕಾರ ಇರುವಲ್ಲಿಯೇ ಇಡುತ್ತದೆ ಮತ್ತು ಸುರಂಗ unit ಅನ್ನು ಮುಟ್ಟದೆ ಬಿಡುತ್ತದೆ:

# /etc/systemd/system/[email protected]
[Unit]
Description=Namespace preparation for %i
Before=openvpn-client@%i.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/netns-up.sh %i
CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target

ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ unit ಅನ್ನು ಸಂಪಾದಿಸುವ ಬದಲು drop-in ನೊಂದಿಗೆ ಕ್ರಮ ಸೇರಿಸಿ, ಇದರಿಂದ ನವೀಕರಣ ನಿಮ್ಮ ಬದಲಾವಣೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬೀಳಿಸಲಾಗದು. ಡೈರೆಕ್ಟರಿ ಇನ್‌ಸ್ಟಾನ್ಸ್ ಹೆಸರಿಗೆ ಬಂಧಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಎರಡನೇ ಪ್ರೊಫೈಲ್‌ಗೆ ತನ್ನದೇ ಫೈಲ್ ಬೇಕು:

sudo mkdir -p /etc/systemd/system/[email protected]
sudo tee /etc/systemd/system/[email protected]/10-namespace.conf >/dev/null <<'CONF'
[Unit]
[email protected]
[email protected]
CONF
sudo systemctl daemon-reload

ಬದಲಾವಣೆಯ ನಂತರ ಅದೇ ಕರೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ

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

ಕೆಳಗಿನ ಕ್ರಮವು ಹೋಲಿಕೆಯನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇಡುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು unit ನ ಬಣ್ಣವನ್ನಲ್ಲ, ನಿರಾಕರಿಸಲಾದ ಕರೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಬದಲಾವಣೆಗೆ ಮೊದಲು ಹಿಡಿದ ಜರ್ನಲ್ ಸಾಲಿನ ಪಕ್ಕದಲ್ಲಿ ಉಳಿಸಿ:

sudo systemctl restart "[email protected]" "[email protected]"
systemctl status "[email protected]" --no-pager
journalctl -u "[email protected]" -b --no-pager | grep -c 'Operation not permitted'
ip -brief addr show tun0

ಕೊನೆಯ ಸಾಲನ್ನು ಓದುವ ಬದಲು ನಿರಾಕರಣೆಗಳನ್ನು ಎಣಿಸಿ, ಏಕೆಂದರೆ ಹುಕ್ ವಿಫಲವಾಗಿ, ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ, ಯಶಸ್ವಿಯಾಗಬಹುದು, ಮತ್ತು ಗಡಿ ಸರಿದಿದೆಯೇ ಎಂದು ಎಣಿಕೆ ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ. drop-in ನಲ್ಲಿ ನೀವು ಸಡಿಲಗೊಳಿಸಿದ ನಿರ್ದೇಶನ ಮತ್ತು ಕಾರಣವನ್ನು ತಿಳಿಸುವ ಟಿಪ್ಪಣಿ ಬಿಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ನವೀಕರಣ ನಿಮ್ಮ ಸಂರಚನೆಯನ್ನು ಪ್ಯಾಕೇಜ್‌ನ ಡೀಫಾಲ್ಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಎಲ್ಲಾ ರಕ್ಷಣೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರವೇ ಪ್ರಾರಂಭವಾಗುವ unit ಸರಿಪಡಿಸಲ್ಪಟ್ಟಿಲ್ಲ.