OpenVPN ಪ್ರೊಫೈಲ್ ಲೋಡ್ ಆದರೂ ca.crt ಹುಡುಕಲಾಗುವುದಿಲ್ಲ

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

ವೈಫಲ್ಯಕ್ಕೆ ಕೆಲವೇ ಕಾರಣಗಳಿವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಕ್ರಮವಾಗಿ ಬೇರ್ಪಡಿಸುವುದು ಯೋಗ್ಯ: ಪ್ರಕ್ರಿಯೆಗೆ ನಿಜವಾಗಿ ಇದ್ದ ಮೂಲ ಡೈರೆಕ್ಟರಿ, ಸೇವೆಯ ಲಾಂಚ್ ಸಂದರ್ಭ, ಮತ್ತು ಮಾರ್ಗ ಸರಿಯಾದ ನಂತರ ಫೈಲ್‌ನ ಸುತ್ತಲಿನ ಅನುಮತಿಗಳು ಅಥವಾ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್. ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಕುರುಹು ಬಿಡುತ್ತದೆ — unit ನಲ್ಲಿ, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಮತ್ತು ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ.

ಪ್ರೊಫೈಲ್ ಮಾರ್ಗ ಮೂಲ ಡೈರೆಕ್ಟರಿ ಅಲ್ಲ

/tmp ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗಿ /etc/vpn/prod/tenant-a.ovpn ಪಡೆಯುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಊಹಿಸಿ. ಆ ಪ್ರೊಫೈಲ್‌ನೊಳಗೆ, ca ca.crt ಸಾಲು ಸಾಪೇಕ್ಷ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಪ್ರೊಫೈಲ್ ಅನ್ನು ಕಂಡುಹಿಡಿದ ಆರ್ಗ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಏನೂ ಆ ಹೆಸರನ್ನು ಮರುಬರೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರಕ್ರಿಯೆ /tmp/ca.crt ಹುಡುಕುತ್ತದೆ ಮತ್ತು ಕಾಣೆಯಾದ ಫೈಲ್ ಬಗ್ಗೆ ವರದಿ ಮಾಡುತ್ತದೆ.

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

ಕೈಪಿಡಿ ಏನನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ: --config ಮತ್ತು --cd

OpenVPN 2.6 ಕೈಪಿಡಿ ಎರಡು ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಒಂದು ಸಂರಚನಾ ಫೈಲ್ ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಇನ್ನೊಂದು ಸಂರಚನೆ, ಕೀಲಿ, ಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಇತರ ಫೈಲ್‌ಗಳನ್ನು ಓದುವ ಮೊದಲು ಪ್ರಕ್ರಿಯೆಯ ಡೈರೆಕ್ಟರಿ ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಸ್ತುತದ ಯಾವುದೇ ಉಲ್ಲೇಖವಿಲ್ಲದ ಸಂಪೂರ್ಣ ಡೈರೆಕ್ಟರಿ ಬೇಡುತ್ತದೆ.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

ಸೇವೆ ಬೇರೆಡೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಪ್ರೊಫೈಲ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ ಸಂವಾದಾತ್ಮಕ ಶೆಲ್ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ unit ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ನಿರ್ವಾಹಕರು ತಮ್ಮದೇ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ ನಿಗದಿಪಡಿಸುತ್ತಾರೆ, ಮತ್ತು ಸುತ್ತುವ ಸ್ಕ್ರಿಪ್ಟ್ ಬೈನರಿ ಚಾಲನೆಯ ಮೊದಲು ಅದನ್ನು ಮತ್ತೆ ಬದಲಾಯಿಸಬಹುದು. ವಿಫಲವಾಗುವ unit ಮಾತ್ರ ಯೋಚಿಸಲು ಯೋಗ್ಯವಾದ ಲಾಂಚ್.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

ಎರಡನೇ ಆಜ್ಞೆ ಜೀವಂತ ಪ್ರಕ್ರಿಯೆ ನಿಜವಾಗಿ ಹಿಡಿದಿರುವ ಡೈರೆಕ್ಟರಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸುತ್ತುವ ಶೆಲ್ ಇದ್ದಾಗ ಇದು unit ಫೈಲ್‌ಗಿಂತ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ. ಎರಡೂ ಒಪ್ಪದಿದ್ದರೆ, ಉತ್ತರ ಸುತ್ತುವ ಶೆಲ್ ಮತ್ತು unit ದಾರಿತಪ್ಪಿಸುವ ಕುರುಹು.

ಹುಡುಕಾಟದ ನಂತರ: ಅನುಮತಿಗಳು, chroot ಮತ್ತು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್

ಸರಿಯಾದ ಮೂಲ ಡೈರೆಕ್ಟರಿ ಕೂಡ ಅದೇ ಸಂದೇಶ ನೀಡಬಹುದು, ಏಕೆಂದರೆ ಪರಿಹಾರ ಮತ್ತು ಪ್ರವೇಶ ಬೇರೆ ಬೇರೆ ಹಂತಗಳು. ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರತಿ ಮೂಲ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅನುಮತಿ ಮತ್ತು ಫೈಲ್‌ನಲ್ಲಿ ಓದುವ ಅನುಮತಿ ಬೇಕು, ಮತ್ತು ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ನ ಭಾಗವನ್ನು ಮರೆಮಾಡುವ ಸೇವಾ unit ಪ್ರಕ್ರಿಯೆ ಏನನ್ನು ನೋಡಬಹುದು ಎಂಬುದನ್ನೇ ಬದಲಾಯಿಸುತ್ತದೆ.

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

ಫೈಲ್‌ನ ಮಾಲೀಕತ್ವ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಗುರುತಿನಿಂದ ನಿರ್ಣಯಿಸಿ, ಅನುಮತಿಗಳನ್ನು ಸಡಿಲಿಸುವ ಮೂಲಕವಲ್ಲ. ಈ ದೋಷವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮಾಡಲು ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಎಲ್ಲರಿಗೂ ಓದಲು ಸಾಧ್ಯವಾಗಿಸುವುದು ಗಟ್ಟಿಯಾದ ವೈಫಲ್ಯವನ್ನು ಮೌನದಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಕೀಲಿಯೇ ಡೈರೆಕ್ಟರಿಯ ನೀವು ಅತ್ಯಂತ ಕಡಿಮೆ ಬಯಲು ಮಾಡಲು ಬಯಸುವ ಭಾಗ.

ನಿಮ್ಮದೇ ಲಾಂಚ್‌ನಿಂದ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಪ್ರೊಫೈಲ್‌ಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಡೈರೆಕ್ಟರಿಯಿಂದ ನಿಜವಾದ unit ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಅದೇ ಪ್ರಾರಂಭ ಸಾಲನ್ನು ಗಮನಿಸಿ. ನಂತರ ಪ್ರಕ್ರಿಯೆ ಚಲಿಸುವಾಗ ಉದ್ದೇಶಿತ ಡೈರೆಕ್ಟರಿ ಹಿಡಿದಿದೆ ಎಂದು ಮತ್ತು ಅದು ಲೋಡ್ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರ ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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