ನಿಮ್ಮ PiVPN ಪ್ರೊಫೈಲ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ಯಾವ OpenVPN ಇನ್ಸ್ಟೆನ್ಸ್ ಬಳಸುತ್ತಿದೆ?

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

ಸಹಾಯಕ ಮತ್ತು ಡೀಮನ್ ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು

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

systemd ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿಯ ಬದಲು ಸಕ್ರಿಯ ಯುನಿಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಹೆಸರು ಪ್ಯಾಕೇಜಿಂಗ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ: Debian ಮತ್ತು Raspberry Pi OS ಇಮೇಜ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಟೆಂಪ್ಲೇಟ್ ಇನ್ಸ್ಟೆನ್ಸ್ ಒದಗಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ openvpn-server@server, ಹಳೆಯ ಸ್ಥಾಪನೆಗಳು openvpn@server ಬಳಸುತ್ತವೆ. ಫೈಲ್ ಹೆಸರಿನಿಂದ ಊಹಿಸುವ ಬದಲು ಯಾವುದು ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ನಿರ್ವಾಹಕರನ್ನು ಕೇಳಿ.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

ಓದಿ ExecStart= ಆ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ. ಅದು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್ ಮತ್ತು ನಿರ್ವಾಹಕ ನಿಜವಾಗಿ ಪ್ರಾರಂಭಿಸುವ ಆಯ್ಕೆಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಯಾವುದೇ --config ಪಥ ಸೇರಿದಂತೆ; ಹತ್ತಿರ ಇರುವ ಮತ್ತು ಯಾವುದೇ ಆದೇಶ ಉಲ್ಲೇಖಿಸದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಸುರಂಗದ ಭಾಗವಲ್ಲ.

ಡೀಮನ್ ಪರಿಹರಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಸರಪಳಿಯನ್ನು ಅನುಸರಿಸಿ

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

ಮನೆ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ .ovpn ಫೈಲ್ ಕ್ಲೈಂಟ್ ಕಲಾಕೃತಿ. ಸರ್ವರ್ ಡೀಮನ್ ಅದನ್ನು ಎಂದಿಗೂ ಓದುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸರ್ವರ್-ಬದಿಯ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವೈಫಲ್ಯ ಸರಿಪಡಿಸಲು ಆ ಫೈಲ್ ಸಂಪಾದಿಸುವುದು ಏನನ್ನೂ ಸಾಧಿಸುವುದಿಲ್ಲ.

ಇನ್‌ಕ್ಲೂಡ್‌ಗಳು ಇನ್ನೊಂದು ಬಲೆ. ಒಂದು config ಸಾಲು ಎರಡನೇ ಫೈಲ್ ಎಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದರ ಆಯ್ಕೆಗಳನ್ನು ಅದೇ ಹಂತದಲ್ಲಿ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಂತರದ ಏಕ-ಮೌಲ್ಯ ಸೂಚನೆ ಮುಖ್ಯ ಫೈಲ್ ಹೇಳುತ್ತಿರುವಂತೆ ತೋರುವುದನ್ನು ಮೀರಿಸಬಹುದು. ಕಾಣುವ ಫೈಲ್ ಸರಿಯಾಗಿ ಕಂಡರೂ ಡೀಮನ್ ಇನ್ನೂ ಬೇರೆ ರೀತಿ ವರ್ತಿಸಿದರೆ, ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಸೇರಿಸಿದ ಫೈಲ್ ಓದಿ.

ಲಾಗ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೆ ಹೊಂದಿಸಿ, ನೀವು ನೆನಪಿಟ್ಟುಕೊಂಡ ದೋಷಕ್ಕೆ ಅಲ್ಲ

ಎರಡು ಲಾಗ್ ಗಮ್ಯಸ್ಥಾನಗಳು ಸಾಮಾನ್ಯ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ journal. log-append ಸೆಟ್ ಆಗಿರುವಾಗ ಡೀಮನ್ ಆ ಫೈಲ್‌ಗೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು journal ಪ್ರಾರಂಭ ಸಾಲುಗಳ ಹೊರತುಪಡಿಸಿ ಸ್ವಲ್ಪವೇ ಉಳಿಸುತ್ತದೆ. ಅದಿಲ್ಲದೆ journalctl ಘಟನೆಗಳ ಮೂಲವಾಗಿದೆ.

journalctl -u openvpn-server@server -n 80 --no-pager

ಒಂದು ಸಂಪರ್ಕ ಪ್ರಯತ್ನವನ್ನು ಒಂದು ಕಾಲ ವಿಂಡೋಗೆ ಹೊಂದಿಸಿ. ಕ್ಲೈಂಟ್‌ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಗಮನಿಸಿ, ನಂತರ ಅದೇ ಸೆಕೆಂಡುಗಳ ಸರ್ವರ್ ಘಟನೆಗಳನ್ನು ಓದಿ. ಪ್ರಮಾಣಪತ್ರ ವಿನಿಮಯವನ್ನು ಎಂದಿಗೂ ತಲುಪದ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ತಲುಪುವಿಕೆ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ದೃಢೀಕರಣ ನಿರಾಕರಣೆ ಸುರಂಗದ ನಿಯತಾಂಕಗಳು ಈಗಾಗಲೇ ಒಪ್ಪಿಗೆಯಾದ ನಂತರ ಬರುತ್ತದೆ.

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

ಕೊನೆಯ ಸಾಮಾನ್ಯ ವೈಫಲ್ಯದ ಬದಲು ಮೊದಲ ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯವನ್ನು ದಾಖಲಿಸಿ. ಬೈಂಡ್ ದೋಷ, ಉತ್ತರವಿಲ್ಲದ ಬಾಹ್ಯ ವಿನಿಮಯ, ಪ್ರಮಾಣಪತ್ರ ನಿರಾಕರಣೆ ಮತ್ತು ಖಾತೆ ನಿರಾಕರಣೆ ಪ್ರತಿಯೊಂದೂ ನಿಮ್ಮನ್ನು ಬೇರೆ ಪದರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯಲ್ಲಿನ ಟೈಮೌಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಮೇಲಿನ ಉಪಯುಕ್ತ ಘಟನೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ.

ಸುರಂಗವನ್ನು ಮರುನಿರ್ಮಿಸುವುದು ರೋಗನಿರ್ಣಯದ ಹಂತವಲ್ಲ

ಪ್ರಲೋಭನೆಗೊಳಿಸುವ ಚಿಕ್ಕ ದಾರಿ ಎರಡನೇ, ಸರಳ ಸುರಂಗವನ್ನು ನಿಲ್ಲಿಸುವುದು: ಸ್ಥಿರ ಕೀಲಿ, ಪ್ರಮಾಣಪತ್ರಗಳಿಲ್ಲ, ಹೆಚ್ಚುವರಿ ದೃಢೀಕರಣವಿಲ್ಲ. ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ತಮ್ಮ ನಡುವೆ UDP ಅಥವಾ TCP ರವಾನಿಸಬಲ್ಲವು ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ-ದೃಢೀಕೃತ ನಿಯೋಜನೆ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ನೀವು ಉಳಿಸಿಕೊಳ್ಳಲು ಕೇಳಲಾದ ಭದ್ರತಾ ಮಾದರಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬದಲಾಯಿಸುತ್ತದೆ.

ಅದೇ tls-auth ಅಥವಾ tls-crypt ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ, verify-x509-name ಸಡಿಲಗೊಳಿಸುವ, ಅಥವಾ ಹಸಿರು ಸ್ಥಿತಿಗಾಗಿ ಎರಡನೇ ಅಂಶವನ್ನು ಬಿಟ್ಟುಬಿಡುವ ವಿಷಯಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆ ತೆಗೆದ ಕಾರಣ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಸುರಂಗ ಬೇರೆ ವ್ಯವಸ್ಥೆ, ಸರಿಪಡಿಸಿದ್ದಲ್ಲ.

ಲಾಗ್ ಹೆಸರಿಸಿದ ಪದರದಲ್ಲಿ ಒಂದು ಮಿತವಾದ ಬದಲಾವಣೆ ಮಾಡಿ, ಅದೇ ಯುನಿಟ್ ಮರುಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಆ ಒಂದೇ ಸಂಪರ್ಕ ಪ್ರಯತ್ನವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಅದು ಹೋಲಿಕೆಯನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇರಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಹಿಂತಿರುಗಿಸಬಹುದಾದ ಬದಲಾವಣೆಯನ್ನು ಬಿಡುತ್ತದೆ.

ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಏನನ್ನು ನೀಡಬೇಕು

ನಾಲ್ಕು ಸಂಗತಿಗಳನ್ನು ಅವು ಇನ್ನೂ ನಿಮ್ಮ ಬಳಿ ಇರುವಾಗ ಬರೆಯಿರಿ: OpenVPN ಆವೃತ್ತಿ openvpn --version ಔಟ್‌ಪುಟ್‌ನಿಂದ, ಸಕ್ರಿಯ ಯುನಿಟ್, ಇನ್‌ಕ್ಲೂಡ್‌ಗಳೊಂದಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಸರಪಳಿ, ಮತ್ತು ಒಂದು ಪ್ರಯತ್ನವನ್ನು ಆವರಿಸುವ ಲಾಗ್ ವಿಂಡೋ. ಆ ನಾಲ್ಕು ಅಸ್ಪಷ್ಟ ದೂರನ್ನು ಮರುಉತ್ಪಾದಿಸಬಹುದಾದ ಪ್ರಕರಣವಾಗಿ ಬದಲಿಸುತ್ತವೆ.

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

ಸರಪಳಿ ಅಖಂಡವಾಗಿದ್ದು ಲಾಗ್ ಇನ್ನೂ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ತೋರಿಸುತ್ತಿದ್ದರೆ, ಮುಂದಿನ ಹೆಜ್ಜೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಪಥ, ಇನ್ನೊಂದು ಸ್ಥಾಪನೆ ಅಲ್ಲ. ಅದು ಸಹಾಯಕ ಎಂದಿಗೂ ಹೊಂದಿರದ ಕಥೆಯ ಭಾಗ.