ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲದೆ OpenVPN: ಸರ್ವರ್ ನೀತಿ, ಪ್ರೊಫೈಲ್ ಅಲ್ಲ

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

ಪ್ರೊಫೈಲ್ ನೀತಿಯಲ್ಲ

Community OpenVPN 2.6 ಕಡ್ಡಾಯ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಬರುತ್ತದೆ, ಏಕೆಂದರೆ verify-client-cert ಪೂರ್ವನಿರ್ಧಾರಿತವಾಗಿ require ಆಗಿದೆ. ಅದನ್ನು none ಗೆ ಹೊಂದಿಸುವುದೇ ಪ್ರಮಾಣಪತ್ರದ ಬೇಡಿಕೆಯನ್ನು ನಿಲ್ಲಿಸಿ ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣವನ್ನು ಸರ್ವರ್ ಈಗಾಗಲೇ ನಡೆಸುತ್ತಿರುವ ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಗುಪ್ತಪದ ವ್ಯವಸ್ಥೆಗೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಹಳೆಯ ಮಾರ್ಗದರ್ಶಿಗಳು ಅದೇ ಕಲ್ಪನೆಯ ಹಳೆಯ ಕಾಗುಣಿತವಾದ client-cert-not-required ಗೆ ಕೈಚಾಚುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಸ್ಥಾಪಿತ ಆವೃತ್ತಿ ದಾಖಲಿಸುವ ಸೂಚನೆಯನ್ನು ಬಳಸಿ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಬದಲಾವಣೆ ಸರ್ವರ್ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಅದನ್ನು ಮಾಡಲಾಗದು.

ಕೆಳಗಿನ ತುಣುಕು ಸರ್ವರ್ ಬದಿಯ ಸಂಪೂರ್ಣ ಬದಲಾವಣೆಯಾಗಿದೆ, ಮತ್ತು ಒಂಟಿಯಾಗಿ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ದೃಢೀಕರಣ ಸಂರಚನೆಯಲ್ಲ. verify-client-cert none ಪ್ರಮಾಣಪತ್ರದ ಬೇಡಿಕೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದರೆ username-as-common-name ಖಾತೆಯ ಹೆಸರನ್ನು ನಂತರದ ಕಾಲ್ಬ್ಯಾಕ್ಗಳು ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಫೈಲ್ಗಳು ನೋಡುವ ಗುರುತಾಗಿ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಸಾಲು ಗುಪ್ತಪದವನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪರಿಶೀಲಕ ಇನ್ನೂ ಇರಬೇಕು.

verify-client-cert none
username-as-common-name

ಆ ಪರಿಶೀಲಕವು auth-user-pass-verify ನಿಂದ ನಡೆಸಲ್ಪಡುವ ಪ್ಲಗಿನ್ ಅಥವಾ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ, ಮತ್ತು ಮೇಲಿನ ಯಾವುದೇ ಸಾಲು ಅರ್ಥಪೂರ್ಣವಾಗುವ ಮೊದಲು ಅದು ತನ್ನ ಸ್ಥಳದಲ್ಲಿರಬೇಕು. ಕ್ರಮವನ್ನು ತಿರುಗಿಸಿದರೆ ಸರ್ವರ್ ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರ ಕೇಳದ ಮತ್ತು ಯಾವುದೇ ಖಾತೆಯನ್ನು ಪರಿಶೀಲಿಸದ ಕಿಟಕಿ ನಿಮಗೆ ಸಿಗುತ್ತದೆ.

ಸರ್ವರ್ ಅನ್ನು ಇನ್ನೂ ಏನು ಪರಿಶೀಲಿಸುತ್ತದೆ

ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು TLS ಅನ್ನು ಬಿಟ್ಟುಬಿಡುವುದಲ್ಲ. ಸರ್ವರ್ ತನ್ನ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಕೀಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ CA ನಂಬಿಕೆ ಮತ್ತು ಹೋಸ್ಟ್ಹೆಸ್ ಪರಿಶೀಲನೆಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಅವು ಅದನ್ನು ಮೋಸಗಾರನೊಂದಿಗೆ ಮಾತನಾಡದಂತೆ ತಡೆಯುತ್ತವೆ. ಕ್ಲೈಂಟ್ಗೆ ಇನ್ನು ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲ ಎಂಬ ಕಾರಣಕ್ಕೆ remote-cert-tls server ಅಥವಾ CA ಬಂಡಲ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು ಸಾಮಾನ್ಯ ಮತ್ತು ಗಂಭೀರ ತಪ್ಪು ಓದಿಕೆ, ಮತ್ತು 2.6 ಉಲ್ಲೇಖ ಎರಡು ದಿಕ್ಕುಗಳು ಸ್ವತಂತ್ರ ಎಂದು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ಒಂದು ಸರ್ವರ್ ಅನ್ನು ಕ್ಲೈಂಟ್ಗೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಅನ್ನು ಸರ್ವರ್ಗೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಪ್ರೊಫೈಲ್ tls-auth ಅಥವಾ tls-crypt ಬ್ಲಾಕ್ ಅನ್ನು ಸಹ ಹೊಂದಿರಬಹುದು. ಅದು ತನ್ನದೇ ವಿತರಣೆ ಮತ್ತು ತಿರುಗುವಿಕೆ ಚಕ್ರವನ್ನು ಹೊಂದಿರುವ ಹಂಚಿಕೆಯ ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ಕೀ, ಆದ್ದರಿಂದ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಕೀ ಸಾಲುಗಳಿಲ್ಲದ ಫೈಲ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಕಟಿಸಲು ಸುರಕ್ಷಿತವಲ್ಲ. ನೀವು ಅದನ್ನು ಓದುವವರೆಗೆ ರಹಸ್ಯವಾಗಿ ಪರಿಗಣಿಸಿ.

ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪ್ರೊಫೈಲ್ನಿಂದ ನಕಲಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಫೈಲ್ ತಾನಾಗಿಯೇ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ; ಸ್ವಾಮ್ಯ ಎಂದರೆ ಅದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಖಾಸಗಿ ಕೀಯನ್ನು ಹೊಂದಿರುವುದು, ಅದನ್ನು ಪ್ರಮಾಣಪತ್ರ-ದೃಢೀಕೃತ ನಿಯೋಜನೆ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೊಂದಿರುವ ಫೈಲ್ ಅದರಿಂದ ದೃಢೀಕರಿಸಬಹುದಾದ ಫೈಲ್ ಅಲ್ಲ.

ಪರಿಶೀಲಕ ಏನು ಮಾಡಬೇಕು

ಪ್ರಮಾಣಪತ್ರದ ಬೇಡಿಕೆಯನ್ನು ತೆಗೆದ ನಂತರ ಎಲ್ಲವೂ ಪರಿಶೀಲಕದ ಮೇಲೆ ನಿಂತಿದೆ: ಪ್ಲಗಿನ್, ಅಥವಾ auth-user-pass-verify ನಿಂದ ನಡೆಸಲ್ಪಡುವ ಸ್ಕ್ರಿಪ್ಟ್. ಅದು ಅಮಾನ್ಯ ರುಜುವಾತುಗಳನ್ನು ತಿರಸ್ಕರಿಸಬೇಕು, ನಿಷ್ಕ್ರಿಯ ಅಥವಾ ಅನರ್ಹ ಖಾತೆಗಳನ್ನು ತಿರಸ್ಕರಿಸಬೇಕು, ಮತ್ತು ತನ್ನ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ತಲುಪದಿದ್ದಾಗ ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗಬೇಕು. username-as-common-name ಸಾಮಾನ್ಯವಾಗಿ ಜೊತೆಗೆ ಸಕ್ರಿಯವಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ನಂತರದ ಕಾಲ್ಬ್ಯಾಕ್ಗಳು ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸಂರಚನಾ ಫೈಲ್ಗಳು ನೋಡುವ ಗುರುತನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅದು ಗುಪ್ತಪದವನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅನರ್ಹ ಖಾತೆಯನ್ನು ಅರ್ಹವಾಗಿಸುವುದಿಲ್ಲ. ಅವು ಪ್ರತ್ಯೇಕ ಕೆಲಸಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಬೆರೆಸುವುದೇ ವಲಸೆಯು ತನ್ನ ಸುಖಮಯ-ಮಾರ್ಗ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿ ತನ್ನ ಮೊದಲ ನಿಜವಾದ ಘಟನೆಯಲ್ಲಿ ವಿಫಲವಾಗುವ ರೀತಿ.

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

ನೀತಿ, ಪ್ರೊಫೈಲ್ ಮತ್ತು ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಬದಲಾಯಿಸಿ

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

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

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