opt-verify ಸೇರಿಸುವುದರಿಂದ OpenVPN ಸೈಫರ್ ದೋಷ ಏಕೆ ಸರಿಯಾಗುವುದಿಲ್ಲ

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

ಸಾಲು ಮೊದಲು ಏನು ಮಾಡುತ್ತಿತ್ತು ಎಂಬುದನ್ನು ತಿಳಿಯುವುದು ಸಹಾಯಕ, ಅದೇ ಕಾಣೆಯಾದ ಭಾಗ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು. ಇತಿಹಾಸವು ಈಗ ಅದು ಏಕೆ ಸಹಾಯ ಮಾಡಲಾಗದು ಎಂಬುದನ್ನೂ ವಿವರಿಸುತ್ತದೆ.

ಆಯ್ಕೆಯು ಮೊದಲು ಏನನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತಿತ್ತು

2.6ರ ಕೈಪಿಡಿಯು opt-verify ಅನ್ನು ಅಸಮ್ಮತ ಎಂದು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ: ಘೋಷಿತ ಆಯ್ಕೆಗಳು ತನ್ನವಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸರ್ವರ್ ಬಿಡುತ್ತದೆ, ಸಾಧನದ ಪ್ರಕಾರ ಮತ್ತು MTU ಮುಂತಾದವನ್ನು ಹೋಲಿಸುತ್ತದೆ. ಆ ಪರಿಶೀಲನೆಯು ಆಯ್ಕೆ-ಸುಸಂಗತತೆಯ ಪರಿಶೀಲನೆ ಸಕ್ರಿಯವಾಗಿರುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ disable-occ ನೊಂದಿಗೆ ಚಾಲನೆಯಾಗುವ ಸರ್ವರ್‌ನಲ್ಲಿ ಅದು ಮೊದಲಿನಿಂದಲೂ ಇರಲಿಲ್ಲ. ಹೋಲಿಕೆಯು ಯಾವುದರಿಂದ ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಇನ್ನೊಂದು ಬದಿಯ ಸಂರಚನೆಯನ್ನು ವಿವರಿಸುವ ಪಠ್ಯ. ಡೇಟಾ ಚಾನೆಲ್ ಯಾವ ಸೈಫರ್ ಬಳಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಫ್ಲ್ಯಾಗ್ ಸೈಫರ್ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲಾಗದ ಮೊದಲ ಕಾರಣ ಇದು. ಸೈಫರ್ ಆಯ್ಕೆಯು data-ciphers ನೀತಿ ಮತ್ತು ಎರಡೂ ಕಡೆಗಳು ಬೆಂಬಲಿಸುವುದರಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಪಠ್ಯ ಸುಸಂಗತತೆಯ ಪರಿಶೀಲನೆ ಆ ಪಟ್ಟಿಯನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ ಅಥವಾ ಮಾತುಕತೆಯನ್ನು ನಡೆಸುವುದಿಲ್ಲ. ಎರಡನೇ ಕಾರಣ ವ್ಯಾಪ್ತಿ: ಪರಿಶೀಲನೆಯು ಘೋಷಿತ ಆಯ್ಕೆಗಳು ಹೊಂದಿಕೆಯಾಗಿ ಕಾಣುತ್ತವೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ, ಪರಿಣಾಮವಾಗಿ ಬರುವ ಮಾರ್ಗದ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಅಲ್ಲ.

2.7 ಸಾಲನ್ನು ಕಂಡಾಗ ಏನು ಮಾಡುತ್ತದೆ

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

ಆದ್ದರಿಂದ ಪಾರ್ಸ್ ಆಗುವ ಪ್ರೊಫೈಲ್ ಯಾವುದೇ ಪ್ರವೇಶ ಪರಿಶೀಲನೆ ನಡೆದಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ನಿಮ್ಮ ಏಕೈಕ ಸಂಕೇತ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದ್ದು ಎಂದಾದರೆ, ವಾಕ್ಯರಚನೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ನೀವು ತಿಳಿದಿದ್ದೀರಿ.

ವೈಫಲ್ಯವು ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ

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

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

ಸಾಲನ್ನು ಮಾತ್ರವಲ್ಲ, ಉದ್ದೇಶವನ್ನೂ ಬದಲಿಸಿ

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

ಎಲ್ಲಾ ಸೈಫರ್‌ಗಳು ನಿಷ್ಕ್ರಿಯಗೊಂಡಿವೆ ಎಂಬ ಹಳೆಯ ಸಲಹೆಗೆ ಪ್ರತಿಯೊಂದು ಐತಿಹಾಸಿಕ ಅಲ್ಗಾರಿದಮ್ ಸಕ್ರಿಯಗೊಳಿಸಿ ಉತ್ತರಿಸಬೇಡಿ.

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

ಗುರಿಯು ಬೆಂಬಲಿತ ನಿರ್ಬಂಧ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ದೃಢೀಕೃತ ಮಾರ್ಗವಾಗಿದೆ, ಇನ್ನೂ ಪಾರ್ಸ್ ಆಗುವ ಹಳೆಯ ಫ್ಲ್ಯಾಗ್ ಅಲ್ಲ.