ಸರಿಯಾದ VPN ಪಾಸ್ವರ್ಡ್ ಕಾಣೆಯಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬದಲಿಸಲಾಗದು

ರುಜುವಾತುಗಳು ಸರಿಯಾಗಿವೆ, ಪ್ರೊಫೈಲ್ ಸ್ವಚ್ಛವಾಗಿ ಆಮದಾಗುತ್ತದೆ, ಮತ್ತು ದೃಢೀಕರಣ ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲೇ ಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತದೆ. Windows ನಲ್ಲಿ ಸಂದೇಶವು EAP ವಿಧಾನಕ್ಕೆ ಸಿಗದ ಪ್ರಮಾಣಪತ್ರದ ಬಗ್ಗೆ ದೋಷ 798 ಆಗಿರಬಹುದು. OpenVPN ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಲಾಗ್ ಸರ್ವರ್ ಅನ್ನು ಎಂದಿಗೂ ತೃಪ್ತಿಪಡಿಸದ TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ಕಾಣೆಯಾದ ವಸ್ತುವನ್ನು ವಿವರಿಸುತ್ತವೆ: ಕ್ಲೈಂಟ್ ಪ್ರಸ್ತುತಪಡಿಸಬೇಕಿದ್ದ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ.

ಪಾಸ್ವರ್ಡ್ ರಹಸ್ಯದ ಜ್ಞಾನವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಪ್ರಮಾಣಪತ್ರವು ಕೀಲಿಯ ಹೊಂದಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ಇನ್ನೊಂದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಪಾಸ್ವರ್ಡ್ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ

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

ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಸಂದೇಶವನ್ನು ಓದಿ. ರುಜುವಾತು ನಿರಾಕರಣೆ, ಪ್ರಮಾಣಪತ್ರ ಹುಡುಕಾಟದ ವೈಫಲ್ಯ ಮತ್ತು TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ವೈಫಲ್ಯ ಮೂರು ವಿಭಿನ್ನ ಸಂಶೋಧನೆಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಪಾಸ್ವರ್ಡ್ಗೆ ಸಂಬಂಧಿಸಿದೆ.

ಕ್ಲೈಂಟ್ ಸ್ಟೋರ್ನಲ್ಲಿ ಏನಿರಬೇಕು

ಎರಡು ವಸ್ತುಗಳು ಒಳಗೊಂಡಿವೆ. ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು VPN ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸುವ ಬಳಕೆದಾರರಿಗೆ ಅದರ ಖಾಸಗಿ ಕೀಲಿಯೊಂದಿಗೆ ಸ್ಥಾಪಿಸಬೇಕು, ಮತ್ತು ನೀಡುವ ಮೂಲವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಬೇಕು. .cer ಫೈಲ್ ಸಾರ್ವಜನಿಕ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಒಂಟಿಯಾಗಿ ಯಾವುದನ್ನೂ ದೃಢೀಕರಿಸಲಾರದು. Windows ಪ್ರಮಾಣಪತ್ರ ನಿರ್ವಾಹಕದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಗುರುತು ಪ್ರಸ್ತುತ ಬಳಕೆದಾರರ ವೈಯಕ್ತಿಕ ಸ್ಟೋರ್ನಲ್ಲಿದೆ, ಮತ್ತು ಮೂಲವು ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲ ಸ್ಟೋರ್ನಲ್ಲಿದೆ.

ಗುರುತನ್ನು ಯಂತ್ರ ಸ್ಟೋರ್ನಲ್ಲಿ, ಅಥವಾ ಮೂಲ ಸ್ಟೋರ್ನಲ್ಲಿ ಮಾತ್ರ ಸ್ಥಾಪಿಸುವುದು ಬಳಕೆದಾರರ ವೈಯಕ್ತಿಕ ಸ್ಟೋರ್ ಅನ್ನು ಗುರಿಯಾಗಿಸಿದ ಹುಡುಕಾಟವನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ. ಸ್ಟೋರ್, ಖಾಸಗಿ-ಕೀಲಿ ಫ್ಲ್ಯಾಗ್ ಮತ್ತು ಮಾನ್ಯತೆಯ ದಿನಾಂಕಗಳನ್ನು ಒಟ್ಟಿಗೆ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಸ್ಟೋರ್ ಅನ್ನು ಮತ್ತೆ ಓದಲು ಕ್ಲೈಂಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.

ಎರಡು ಉತ್ಪನ್ನಗಳು, ಅದೇ ಕಾಣೆಯಾದ ರುಜುವಾತು

OpenVPN ಸರ್ವರ್ಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬೇಡುತ್ತವೆ. ಕ್ಲೈಂಟ್ಗೆ auth-user-pass ಸೇರಿಸಿದರೆ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ಇನ್ನೂ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೇವಲ ಪಾಸ್ವರ್ಡ್ verify-client-cert require ಅಡಿಯಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾರದು. ಸರ್ವರ್ ಏನನ್ನೂ ಬೇಡದಂತೆ ಹೊಂದಿಸಬಹುದು, ಇದು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಕ್ಲೈಂಟ್ನ ಏಕೈಕ ರುಜುವಾತಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇದು ಶಕ್ತಿಯಲ್ಲಿ ನಿಜವಾದ ಕಡಿತವಾಗಿದೆ. auth-user-pass-verify ಹಿಂದಿನ shell ಸ್ಕ್ರಿಪ್ಟ್ ರುಜುವಾತುಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸಬಹುದು, ಮತ್ತು ಅದಕ್ಕೆ ಸ್ಕ್ರಿಪ್ಟ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಇದು ಸೂಕ್ತವಾದ ದೃಢೀಕರಣ ಬ್ಯಾಕೆಂಡ್ಗಿಂತ ಹೆಚ್ಚು ಅಪಾಯಕಾರಿ ವಿನ್ಯಾಸವಾಗಿಸುತ್ತದೆ.

ಕೇವಲ ಪಾಸ್ವರ್ಡ್ ಆಧಾರಿತ ಪ್ರೊಫೈಲ್ ತಳ್ಳಲಾದ ಆಯ್ಕೆಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಅವು ಪುನಃ ಎಳೆಯುವ ವ್ಯವಸ್ಥೆ ಸಕ್ರಿಯವಾಗಿರುವುದನ್ನು ಅವಲಂಬಿಸಿವೆ.

ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಕಾಣೆಯಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸರಿಪಡಿಸಬೇಡಿ

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

ಪ್ರಮಾಣಪತ್ರ ಯಾವ ಸ್ಟೋರ್ನಲ್ಲಿತ್ತು, ಯಾವ ಬಳಕೆದಾರ ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸಿದರು ಮತ್ತು ಖಾಸಗಿ ಕೀಲಿ ಇತ್ತೋ ಇಲ್ಲವೋ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಆ ಮೂರು ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ಪ್ರಕರಣವನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಪಾಸ್ವರ್ಡ್ ಸರಿಯಾಗಿತ್ತು. ವಿಧಾನಕ್ಕೆ ನಿಜವಾಗಿ ಬೇಕಿದ್ದ ರುಜುವಾತು ಬೇರೆ ಎಲ್ಲೋ ಇತ್ತು.