OpenSSL 3 ನಂತರ OpenVPN ಕೀ ಪ್ರಾಂಪ್ಟ್: ಪೂರೈಕೆದಾರರನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಮೊದಲ ಪ್ರಶ್ನೆ ಕೀ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆಯೇ ಎಂಬುದು, ಎರಡನೆಯದು ಈ ಬಿಲ್ಡ್ ಅದನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಲ್ಲದೇ ಎಂಬುದು. ಎರಡೂ ಉತ್ತರಗಳು ತಿಳಿದ ನಂತರವೇ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳಿಗೆ ಅರ್ಥವಿದೆ.

ಕೀ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಫೈಲ್ನ ಮೊದಲ ಸಾಲನ್ನು ಓದಿ, ನಂತರ ಲೈಬ್ರರಿಯನ್ನು ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಬಿಡಿ, ಏಕೆಂದರೆ ಫೈಲ್ ಹೆಸರು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಲೇಬಲ್ ಹೊಂದಿರುವ PEM ಬ್ಲಾಕ್ ENCRYPTED PRIVATE KEY ಎನ್ಕ್ರಿಪ್ಟೆಡ್ PKCS#8 ಆಗಿದೆ, ಮತ್ತು ಹಳೆಯ RSA PRIVATE KEY ಬ್ಲಾಕ್ Proc-Type: 4,ENCRYPTED ಅನ್ನು ಹೊಂದಿರುವುದು ಸಾಂಪ್ರದಾಯಿಕ ರೂಪ, ಮತ್ತು ಎರಡೂ ಪಾಸ್ಫ್ರೇಜ್ ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡದ PRIVATE KEY ಬ್ಲಾಕ್ ಅದನ್ನು ಮೊದಲೇ ಕೇಳಬಾರದು. ಫೈಲ್ ಅನ್ನು ಹೊಂದಿರುವ ಖಾತೆಯಿಂದಲೇ ಪಾರ್ಸಿಂಗ್ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಅನುಮತಿ ಸಮಸ್ಯೆ ಬೇರೆಯದೇ ಮತ್ತು ತುಂಬಾ ಕಡಿಮೆ ಆಸಕ್ತಿಕರ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ.

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

ಈ ಬಿಲ್ಡ್ ಅದನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಲ್ಲದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

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

ಲಭ್ಯವಿರುವ ಅತ್ಯಂತ ಸಣ್ಣ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಸಿಸ್ಟಂ-ವ್ಯಾಪಿ ಬದಲಾವಣೆಗಿಂತ ಕ್ಲೈಂಟ್ಗೆ ಸೀಮಿತವಾದ ಬದಲಾವಣೆಗೆ ಆದ್ಯತೆ ನೀಡಿ. ಕೆಲವು 2.6 ಬಿಲ್ಡ್ಗಳು ಆ ಡೀಮನ್ ಪ್ರಕ್ರಿಯೆಗೆ ಎರಡೂ ಪೂರೈಕೆದಾರರನ್ನು ಲೋಡ್ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಆಯ್ಕೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ನಿಮ್ಮ ನಿಖರ ಆವೃತ್ತಿಯ ಕೈಪಿಡಿಯಲ್ಲಿ ಸೂಚನೆಯನ್ನು ದೃಢೀಕರಿಸಿ; ಬದಲಿಗೆ ಸಿಸ್ಟಂನ openssl.cnf ಸಂಪಾದಿಸುವುದು ಹೋಸ್ಟ್ನ ಪ್ರತಿ OpenSSL ಪ್ರೋಗ್ರಾಂಗೂ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಕೀ ಮರು-ಎನ್ಕೋಡ್ ಆದ ನಂತರ ಕಿರಿದಾದ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುವುದೂ ತುಂಬಾ ಸುಲಭ.

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

ಸೇವೆಯ ಸಂದರ್ಭವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರು-ಎನ್ಕೋಡ್ ಮಾಡಿ

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

ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಘಟಕವನ್ನು ಪರಿಶೀಲಿಸಿ. ನಿಮ್ಮ ಶೆಲ್ನಲ್ಲಿ ಓದಬಹುದಾದ ಕೀ ಬೇರೆ ಖಾತೆಯ ಅಡಿಯಲ್ಲಿ ಅಥವಾ ಕಠಿಣಗೊಳಿಸಿದ ಮನೆ ಡೈರೆಕ್ಟರಿ ಸೆಟ್ಟಿಂಗ್ನೊಂದಿಗೆ ಚಲಿಸುವ ಸೇವೆಗೆ ಓದಲಾಗದಂತಿರಬಹುದು.

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

ಪ್ರಾಂಪ್ಟ್ ಕನಿಷ್ಠ ಮೂರು ಕಾರಣಗಳಿರುವ ಲಕ್ಷಣ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಕಾಣೆಯಾದ ಪಾಸ್ಫ್ರೇಜ್.