OpenVPN ಪ್ರೊಫೈಲ್‌ನಿಂದ key-method ತೆಗೆದರೆ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ

ವರ್ಷಗಳಿಂದ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಪ್ರೊಫೈಲ್ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪ್ರಾರಂಭವಾಗಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸಂದೇಶವು ಯಾರೂ ಸೇರಿಸಿದ್ದು ನೆನಪಿಲ್ಲದ ಆದೇಶವನ್ನು ಹೆಸರಿಸುತ್ತದೆ: key-method. ಮುಂದಿನ ಹುಡುಕಾಟ ಫಲಿತಾಂಶವು ಹೊಂದಾಣಿಕೆಗಾಗಿ key-method 2 ಸೇರಿಸಲು ಸೂಚಿಸುತ್ತದೆ, ಅದು ಬೇರೆ ಯುಗದ ಸಲಹೆ. ಸಾಲನ್ನು ತಿರಸ್ಕರಿಸಿದ ಪಾರ್ಸರ್ ಪ್ರಸ್ತುತ ಇರುವುದು, ಮತ್ತು ಅದರಲ್ಲಿ ಅಂತಹ ಆಯ್ಕೆಯೇ ಇಲ್ಲ. ಸಾಲನ್ನು ತೆಗೆದರೆ ಆರಂಭ ಸರಿಹೋಗುತ್ತದೆ, ಮತ್ತು ಎರಡು ಬದಿಗಳು ಸೆಷನ್ ಅನ್ನು ಹೇಗೆ ರಕ್ಷಿಸುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

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

ಲಕ್ಷಣವು ಪಾರ್ಸ್ ದೋಷ, ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವೈಫಲ್ಯವಲ್ಲ

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

ಸಂದೇಶವು ಆದೇಶವನ್ನು ಹೆಸರಿಸಿದರೆ, ರೋಗನಿರ್ಣಯ ಮುಗಿದಿದೆ: ಈ ಬಿಲ್ಡ್ ಸ್ವೀಕರಿಸದ ಯಾವುದೋ ಒಂದು ಕಡತದಲ್ಲಿದೆ. ಸಂದೇಶವು ಬದಲಾಗಿ ಕಡತ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸಿದರೆ, ಸಮಸ್ಯೆ ಕಾಣೆಯಾದ include ಅಥವಾ ಕೀ, ಅದು ಅದೇ ಆರಂಭಿಕ ಹಂತದ ಇನ್ನೊಂದು ಭಾಗ.

ನೀವು ತೀರ್ಮಾನಿಸಬಾರದುದು ಎಂದರೆ ಕ್ಲೈಂಟ್ ಅಥವಾ ಸರ್ವರ್‌ಗೆ ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ ಮೋಡ್ ಬೇಕು ಎಂದು. ಪಾರ್ಸ್ ವೈಫಲ್ಯವು ನಿಮ್ಮ ಕಡತ ಮತ್ತು ಬೈನರಿ ನಡುವಿನ ಪದಸಂಪತ್ತಿನ ಸಮಸ್ಯೆ, ಮತ್ತು ಬೈನರಿ ಈ ಸಂದರ್ಭದಲ್ಲಿ ತನ್ನ ಪದಸಂಪತ್ತಿನಿಂದ ಒಂದು ಪದವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿದೆ.

ಆದೇಶ ಮತ್ತು ವಾಯರ್ ಸ್ವರೂಪ ಎರಡು ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳು

ಹಳೆಯ key-method ಆಯ್ಕೆಯು TLS ಕೀ-ವಿನಿಮಯವನ್ನು ಹೇಗೆ ಚೌಕಟ್ಟಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಿತ್ತು, ಮತ್ತು ಆಧುನಿಕ ವಿನಿಮಯವು ಆ ಆಯ್ಕೆ ಒಮ್ಮೆ ಕೇಳಿದ್ದ ಬಹು-ಪ್ಯಾಕೆಟ್ ವಿಧಾನವಾಗಿದೆ. ಆಯ್ಕೆ ಹೋಗಿಬಿಟ್ಟಿತು ಏಕೆಂದರೆ ಅದು ಇನ್ನು ಯಾವುದನ್ನೂ ಆಯ್ಕೆ ಮಾಡುತ್ತಿರಲಿಲ್ಲ; ಅದು ಹೆಸರಿಸಿದ ಸ್ವರೂಪವೇ ಏಕೈಕವಾಯಿತು. ಆದ್ದರಿಂದ ಸಾಲನ್ನು ತೆಗೆದರೆ ಸೆಷನ್ ಮೊದಲಿನಂತೆಯೇ ಅದೇ ಚೌಕಟ್ಟಿನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. ಪಠ್ಯ ಸಂಪಾದನೆ ಅದನ್ನು ಯಾವ ದಿಕ್ಕಿನಲ್ಲೂ ಬದಲಿಸಲಾರದು.

ಅದಕ್ಕಾಗಿಯೇ “2ನೇ ವಿಧಾನವನ್ನು ಮರುಸ್ಥಾಪಿಸಲು” ಹಳೆಯ ಬೈನರಿಯನ್ನು ಮರಳಿ ತರುವುದು ತಪ್ಪು ದುರಸ್ತಿ. ಅದು ಹಳೆಯ ಡೀಫಾಲ್ಟ್‌ಗಳಿರುವ ಹಳೆಯ ಪಾರ್ಸರ್ ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ಮರುಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ನಂತರ ಬಂದ ಸರಿಪಡಿಸುವಿಕೆಗಳನ್ನು ನಿಮಗೆ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದೇ ತರ್ಕ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಅಥವಾ ಸೈಫರ್ ಪಟ್ಟಿಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುವುದಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಸಂಪರ್ಕ ಮರಳಿ ಬರುತ್ತದೆ ಎಂಬ ನಿರೀಕ್ಷೆಯಲ್ಲಿ.

ಉಪಯುಕ್ತ ಪರಿಶೀಲನೆ ಎಂದರೆ ಆವೃತ್ತಿ ಮತ್ತು ಪಾರ್ಸ್ ಮಾಡಿದ ಸಂರಚನೆ, ಕಡತದಲ್ಲಿ ಪದದ ಇರುವಿಕೆ ಅಲ್ಲ:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

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

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

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

ನಂತರ ಉದ್ದೇಶಿತ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಅದರ ಆರಂಭಿಕ ಔಟ್‌ಪುಟ್ ಓದಿ. ಶ್ರೋತೃ ಇರುವ ಸ್ಥಿತಿಯಲ್ಲಿ ಸ್ವಚ್ಛ ಪ್ರಾರಂಭವೇ ಈ ಹಂತ ಮುಗಿದಿದೆ ಎಂಬ ದೃಢೀಕರಣ; ನಂತರದ ಕ್ಲೈಂಟ್ ಪರೀಕ್ಷೆ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ತಿರಸ್ಕೃತ ಪ್ರೊಫೈಲ್ ಮತ್ತು ತಿರಸ್ಕೃತ ಕ್ಲೈಂಟ್ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ

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

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

ಸಾಲು ಎಂದಿಗೂ ಉತ್ತರಿಸದ ಹೊಂದಾಣಿಕೆ ಪ್ರಶ್ನೆಗಳು

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

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

ನೀವು ಏನನ್ನು ತೆಗೆದುಕೊಂಡರು ಮತ್ತು ಏಕೆ ಎಂಬುದರ ಸಣ್ಣ ದಾಖಲೆ ಇಟ್ಟುಕೊಳ್ಳಿ: ಆಯ್ಕೆ, ಅದನ್ನು ತಿರಸ್ಕರಿಸಿದ ಆವೃತ್ತಿ, ಮತ್ತು ದೋಷವನ್ನು ತೋರಿಸಿದ ಆಜ್ಞೆ. ಪ್ರೊಫೈಲ್ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುವ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ನಿಖರವಾಗಿ ಆ ಮೂರು ಸಂಗತಿಗಳು ಬೇಕಾಗುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಈಗ ಬರೆಯುವುದು ನಂತರ ಮರುನಿರ್ಮಿಸುವುದಕ್ಕಿಂತ ಅಗ್ಗ.