OpenVPN ಸೇವೆಯಾದ ನಂತರ client-config-dir ನಿರ್ಲಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ

ನಿಮ್ಮ ಸುರಂಗ ಏರುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಸ್ಥಿರ ವಿಳಾಸ ಮತ್ತು ಆ ಒಬ್ಬ ಬಳಕೆದಾರರಿಗಾಗಿ ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳು ಕಾಣೆಯಾಗಿವೆ. ಲಾಗ್‌ನಲ್ಲಿ “file not found” ಎಂದು ಬರೆದಿಲ್ಲ, ಮತ್ತು ಇದೇ ಜನರನ್ನು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮತ್ತೆ ರಚಿಸಲು ಕಳುಹಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಹುಪಾಲು ಡೀಮನ್ ನೀವು ಪರೀಕ್ಷಿಸಿದ ಶೆಲ್‌ಗಿಂತ ಬೇರೆ ಡೈರೆಕ್ಟರಿಯಿಂದ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು client-config-dir ನೀವು ಊಹಿಸಿದಂತೆ ಎಂದಿಗೂ ಪರಿಹರಿಸಲ್ಪಟ್ಟಿಲ್ಲ. ಸರಿಪಡಿಸುವಿಕೆ ಮಾರ್ಗದ ತಿದ್ದುಪಡಿ, ರುಜುವಾತುಗಳ ಮರುಹೊಂದಿಕೆ ಅಲ್ಲ.

ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಯುನಿಟ್ ಓದಿ

ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್‌ನಿಂದ ಅಲ್ಲ, ವಾಸ್ತವವಾಗಿ ಚಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ. systemd ಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಲು, ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಅದು ಇಳಿಯುವ ಖಾತೆಯನ್ನು ಕೇಳಿ. ಆ ಮೂರು ಉತ್ತರಗಳು ಈ ವರ್ಗದ ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

ಖಾಲಿ WorkingDirectory ಎಂದರೆ ಯುನಿಟ್ / ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಪೇಕ್ಷ client-config-dir ccd /ccd ನಲ್ಲಿ ಹುಡುಕಲಾಗುತ್ತದೆ. ಆ ಡೈರೆಕ್ಟರಿ ಬಹುತೇಕ ಎಂದಿಗೂ ಇರುವುದಿಲ್ಲ, ಮತ್ತು ಡೀಮನ್ ಅದರ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಮಾರಕವೆಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ.

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

ಸಾಪೇಕ್ಷ ಮಾರ್ಗ ಯಾವುದಕ್ಕೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ

ಕೀವರ್ಡ್ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿದ ಕ್ಷಣದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಗೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ಇದರ ಅರ್ಥ “ನಾನು --config ಜೊತೆ ರವಾನಿಸಿದ ಸಂರಚನಾ ಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿ” ಎಂದಲ್ಲ. OpenVPN ಸಂಪೂರ್ಣ ಮಾರ್ಗದಿಂದ ಸಂರಚನೆಯನ್ನು ಸಂತೋಷದಿಂದ ಓದುತ್ತದೆ ಮತ್ತು ಸಾಪೇಕ್ಷ ಮೌಲ್ಯಗಳನ್ನು ಇನ್ನೂ ಬೇರೆಡೆ ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಇಲ್ಲಿ ಅದೇ ಬಲೆ. OpenVPN 2.6 ಕೈಪಿಡಿ ನಿಯಮವನ್ನು --client-config-dir ಅಡಿಯಲ್ಲಿ ಮತ್ತು ಮತ್ತೆ --cd ಅಡಿಯಲ್ಲಿ ಹೇಳುತ್ತದೆ.

cd ಕೀವರ್ಡ್ ಬೇರೆ ಫೈಲ್‌ಗಳನ್ನು ಓದುವ ಮೊದಲು ಆ ಸಂದರ್ಭವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ cd /etc/openvpn/server ಹೊಂದಿಸಿ ನಂತರ client-config-dir ccd ಇರಿಸುವ ಯುನಿಟ್ /etc/openvpn/server/ccd ಗೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ನೀವು cd ಸೇರಿಸಿದರೆ, ಸೂಚನೆಗಳ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅದು ಅದೇ ಫೈಲ್‌ನ ಪ್ರತಿ ಸಾಪೇಕ್ಷ ಉಲ್ಲೇಖವನ್ನೂ ಪ್ರಭಾವಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ.

ಮಾರ್ಗವನ್ನು ಡೀಮನ್‌ನ ಖಾತೆಯಾಗಿ ನಡೆಯಿರಿ

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

namei ಪ್ರತಿ ಘಟಕದ ಅನುಮತಿಯನ್ನು ಕ್ರಮವಾಗಿ ಮುದ್ರಿಸುತ್ತದೆ, ಇದು ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಪರಿಶೀಲಿಸುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿದೆ:

namei -l /etc/openvpn/server/ccd/client1

ನಂತರ ಓದುವಿಕೆಯನ್ನು ನೀವೇ ಆಗಿ ಅಲ್ಲ, ಸೇವಾ ಖಾತೆಯಾಗಿ ಪರೀಕ್ಷಿಸಿ:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

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

ಊಹಿಸುವುದರ ಬದಲು ಹುಡುಕಾಟವನ್ನು ದೃಢೀಕರಿಸಿ

ಒಂದು ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಲಾಗ್ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಸರ್ವರ್ ಏನು ಹೇಳುತ್ತದೆ ಎಂದು ಓದಿ. verb 4 ನಲ್ಲಿ ಡೀಮನ್ ಆಮದು ಮಾಡಿದ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಾಣೆಯಾದ ಸಾಲು ಆ ಸಂಪರ್ಕಕ್ಕೆ ಯಾವುದೇ ಫೈಲ್ ಓದಿಲ್ಲ ಎಂಬ ನೇರ ಸಾಕ್ಷಿ.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

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

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

ಸರಿಪಡಿಸಿ, ಮರುಪ್ರಾರಂಭಿಸಿ, ಪರಿಶೀಲಿಸಿ

ಸಂರಚನೆಯಲ್ಲಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿಸಿ ಮತ್ತು ಹಾಗೆಯೇ ಇರಿಸಿ. ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳು ಯುನಿಟ್ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಯನ್ನು ಪಿನ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ಸುರಕ್ಷಿತ, ಮತ್ತು ಪಿನ್ ಮಾಡುವುದು ನಂತರ ಯಾರೋ ತೆಗೆದುಹಾಕುವ ಹೆಚ್ಚುವರಿ ಚಲಿಸುವ ಭಾಗ.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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