tls-auth key-direction: 0 ಮತ್ತು 1 ಭಿನ್ನವಾಗಿರಬೇಕು, ಹೊಂದಿಕೆಯಾಗಬಾರದು
tls-auth ನೊಂದಿಗೆ ಎರಡೂ ತುದಿಗಳಿಗೆ ವಿರುದ್ಧ ದಿಕ್ಕುಗಳು ಬೇಕು, 0 ಮತ್ತು 1, ಅಥವಾ ಎರಡೂ ಸೆಟ್ಟಿಂಗ್ ಬಿಡಬೇಕು. ಅದೇ ಸಂಖ್ಯೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು tls-crypt ಅದನ್ನು ಎಂದಿಗೂ ಬಳಸುವುದಿಲ್ಲ.
ಸುರಂಗದ ಒಂದು ಬದಿ ಇನ್ನೊಂದು ಬದಿ ಎಂದಿಗೂ ಪರಿಶೀಲಿಸದ ಕೀ ಸ್ಲಾಟ್‌ನಿಂದ ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ಗೆ ಸಹಿ ಹಾಕುತ್ತದೆ, ಮತ್ತು ಒಂದೂ ಪ್ರಮಾಣಪತ್ರ ವಿನಿಮಯವಾಗುವ ಮೊದಲೇ ಸಂಪರ್ಕವು ದೃಢೀಕರಣ ದೋಷದಿಂದ ಸಾಯುತ್ತದೆ. tls-auth ನ ದಿಕ್ಕು ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಹೀಗೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಅದು ನಿರ್ಣಾಯಕ: ಅದೇ ಎರಡು ಫೈಲ್‌ಗಳು ಪ್ರತಿ ಪ್ರಯತ್ನದಲ್ಲೂ, ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದಲೂ ವಿಫಲವಾಗುತ್ತವೆ. ನೀವು ಹುಡುಕುತ್ತಿರುವ ಆಯ್ಕೆಯ ಹೆಸರು ಲಾಗ್‌ನಲ್ಲಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಜನರು ಎಂದಿಗೂ ಮುರಿಯದ ಕೀಗಳನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುತ್ತಾರೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮತ್ತೆ ನೀಡುತ್ತಾರೆ. ಪರಿಹಾರ ಎಂದರೆ ಎರಡೂ ತುದಿಗಳನ್ನು ಪೂರಕಗೊಳಿಸುವುದು, ಅಥವಾ ಎರಡನ್ನೂ ದ್ವಿದಿಕ್ಕಿನಂತೆ ಬಿಡುವುದು, ಪರಿಶೀಲನೆಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುವುದಲ್ಲ.
ವೈಫಲ್ಯ ಪ್ರಮಾಣಪತ್ರಗಳಿಗಿಂತ ಮೊದಲು ಬರುತ್ತದೆ
tls-auth ನೊಂದಿಗೆ ಎರಡೂ ಪೀರ್‌ಗಳು ಒಂದೇ ಹಂಚಿದ ಕೀಯನ್ನು ಹಿಡಿದಿವೆ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಅದರಿಂದ ಪಡೆದ ಎರಡು ಸ್ಲಾಟ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಬಳಸುತ್ತದೆ: ಒಂದು ಸ್ಲಾಟ್ ಹೊರಹೋಗುವ ನಿಯಂತ್ರಣ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಸಹಿ ಹಾಕುತ್ತದೆ, ಇನ್ನೊಂದು ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ದಿಕ್ಕು 0 ಮತ್ತು ದಿಕ್ಕು 1 ಈ ಪಾತ್ರಗಳನ್ನು ವಿಲೋಮ ಕ್ರಮದಲ್ಲಿ ನಿಗದಿಪಡಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ HMAC ಪರಿಶೀಲನೆಗಳು ಹೊಂದಿಕೆಯಾಗಲು ಜೋಡಿ ಪೂರಕವಾಗಿರಬೇಕು. ಒಂದು ಬದಿಯಲ್ಲಿ ನಿಗದಿಯನ್ನು ತಿರುಗಿಸಿದಾಗ, ಸ್ವೀಕರಿಸುವವನು ತಪ್ಪು ಸ್ಲಾಟ್‌ನಲ್ಲಿ ಸಹಿ ಹುಡುಕಿ ಪ್ಯಾಕೆಟ್ ತಿರಸ್ಕರಿಸುತ್ತಾನೆ. ಅಲ್ಲೇ ಅಧಿವೇಶನ ಮುಗಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ದೋಷ ಪ್ಯಾಕೆಟ್ ದೃಢೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದ್ದು, ಪ್ರಮಾಣಪತ್ರ ಸಂಗ್ರಹ ಉತ್ಪಾದಿಸುವ ಯಾವುದಕ್ಕೂ ಅಲ್ಲ.
ನಿರ್ಣಾಯಕತೆ ರೋಗನಿರ್ಣಯಕ್ಕೆ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಸಮಯ ಅಥವಾ ಮಾರ್ಗದ ಸಮಸ್ಯೆ ಬೇರೆ ಗುರುತು ಬಿಡುತ್ತದೆ: ಮಧ್ಯಂತರ ಕಡಿತಗಳು, ಒಂದು ದಿಕ್ಕಿನ ವೈಫಲ್ಯ, ಅಥವಾ ನಿರ್ದಿಷ್ಟ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಮಾತ್ರ ಸಾಯುವ ಅಧಿವೇಶನ. ದಿಕ್ಕು ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಪ್ರತಿ ಬಾರಿ ಮೊದಲ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಎರಡು ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಇನ್ನೊಂದು ಯಂತ್ರದಲ್ಲೂ ಅದೇ ರೀತಿ ವಿಫಲವಾಗುತ್ತದೆ. --verb 4 ನಲ್ಲಿ ಲಾಗ್ ಓದಿ ಮತ್ತು ಕೊನೆಯ ಸಾಲಿನ ಬದಲು ಮೊದಲ ತಿರಸ್ಕೃತ ಪ್ಯಾಕೆಟ್ ಹುಡುಕಿ. ಆ ತಿರಸ್ಕಾರ ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರ ವಿನಿಮಯಕ್ಕಿಂತ ಮೊದಲು ಸಂಭವಿಸಿದರೆ, ಹಂಚಿದ ಕೀ ಮತ್ತು ಅದರ ದಿಕ್ಕು ಪರಿಶೀಲಿಸಲು ಯೋಗ್ಯವಾದ ಎರಡು ವಿಷಯಗಳು.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
ಸಂಖ್ಯೆ ಎಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ
OpenVPN 2.6 ಕೈಪಿಡಿ ದಿಕ್ಕಿಗೆ ಎರಡು ಸ್ಥಳಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ: ಕೀ ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ನಲ್ಲಿದ್ದಾಗ tls-auth ನ ಎರಡನೇ ಆರ್ಗ್ಯುಮೆಂಟ್, ಮತ್ತು ಕೀ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಇನ್‌ಲೈನ್ ಆಗಿದ್ದಾಗ ಪ್ರತ್ಯೇಕ key-direction ಸಾಲು. ಎರಡೂ ಒಂದೇ ಮೌಲ್ಯವನ್ನು ಸೆಟ್ ಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಒಂದು ರೂಪ ಅಥವಾ ಇನ್ನೊಂದನ್ನು ಬಳಸಬೇಕು, ಎಂದಿಗೂ ಎರಡನ್ನೂ ಅಲ್ಲ. ಬಿಟ್ಟುಬಿಡುವುದೂ ಒಂದು ಆಯ್ಕೆ, ಮತ್ತು ಅದು ಎರಡೂ ಪೀರ್‌ಗಳನ್ನು ದ್ವಿದಿಕ್ಕಿನ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇಡುತ್ತದೆ, ಯಾವ ಪಕ್ಷವೂ ದಿಕ್ಕು ಹೇಳದಿದ್ದಾಗ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಒಂದೇ ಸಂಖ್ಯೆ ಹೊಂದಿರುವ ಎರಡು ಪೀರ್‌ಗಳು ಆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿಲ್ಲ: ಪ್ರತಿಯೊಂದೂ ಒಂದು ಸ್ಲಾಟ್‌ನಲ್ಲಿ ಸಹಿ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಪರಿಶೀಲನೆ ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಅದನ್ನು ಒಂದೇ ರೀತಿ ಮಾಡುತ್ತವೆ.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ಇನ್‌ಲೈನ್ ರೂಪವು ತನ್ನದೇ ಸಾಲಿನಲ್ಲಿ ನಿರ್ದೇಶನ, ಕೀ ಬ್ಲಾಕ್‌ನ ತೆರೆಯುವ ಟ್ಯಾಗ್‌ನಲ್ಲಿ ಗುಣಲಕ್ಷಣವಲ್ಲ, ಮತ್ತು ಆ ಟ್ಯಾಗ್‌ಗೆ ಆರ್ಗ್ಯುಮೆಂಟ್ ಸೇರಿಸುವುದು ದೋಷ, ದಿಕ್ಕು ಬದಲಾವಣೆಯಲ್ಲ. ಸ್ಥಾನವೂ ಮುಖ್ಯ: ನಿರ್ದೇಶನವು ತಾನು ಸೇರಿದ ಬ್ಲಾಕ್‌ನ ಹೊರಗಿದೆ, ಆದ್ದರಿಂದ ಬ್ಲಾಕ್ ಒಳಗೆ ಬರೆದ ಮೌಲ್ಯವನ್ನು ಕೀ ಸಾಮಗ್ರಿ ಎಂದು ಓದಲಾಗುತ್ತದೆ. ಪ್ರೊಫೈಲ್ ವಿತರಕರು ಉದ್ದೇಶಿಸಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ನಕಲಿಸಿ, ಜೋಡಿ ಕಲ್ಪಿಸುವ ಬದಲು, ಏಕೆಂದರೆ ಒಂದು ಸರ್ವರ್ ವಿರುದ್ಧ ಕೆಲಸ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಬಹುಶಃ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಈಗಾಗಲೇ ಪ್ರತಿಬಿಂಬಿತವಾಗಿದೆ.
ಆಯ್ಕೆ ಏನನ್ನು ಮುಟ್ಟದೆ ಬಿಡುತ್ತದೆ
ಇದು ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದಿಲ್ಲ. tls-auth ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ನ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸುತ್ತ HMAC ಹಾಕುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಚಾನೆಲ್ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯದಲ್ಲಿ ಸಮಾಲೋಚಿಸಿದ ಅಧಿವೇಶನ ಕೀಗಳಿಂದ ರಕ್ಷಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಥ್ರೂಪುಟ್ ಅಥವಾ ಸೈಫರ್ ಪ್ರಶ್ನೆಗೆ ದಿಕ್ಕು ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಸೆಟ್ಟಿಂಗ್ ಎರಡನೇ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಪದರವನ್ನೂ ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಊಹೆಯೇ ಜನರನ್ನು ಉದ್ದವಾದ ಕೀ ಹುಡುಕಲು ಕಳುಹಿಸುತ್ತದೆ.
ಇದು tls-crypt ಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ತನ್ನದೇ ಆಯ್ಕೆಗಳು ಮತ್ತು ಕೀ ನಿರ್ವಹಣೆಯನ್ನು ಹೊಂದಿರುವ ಇನ್ನೊಂದು ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಕಾರ್ಯವಿಧಾನ, ಮತ್ತು ಯಾವುದೇ ಪೀರ್‌ನ ಪ್ರಮಾಣಪತ್ರ ಗುರುತಿನ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ದಿಕ್ಕು ಹೊಂದಾಣಿಕೆ ಎರಡೂ ತುದಿಗಳು ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಅನ್ನು ಹೇಗೆ ದೃಢೀಕರಿಸಬೇಕೆಂದು ಒಪ್ಪುತ್ತವೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ವಿಶ್ವಾಸ ಸರಪಳಿ ಮಾನ್ಯವಾಯಿತು ಎಂಬುದನ್ನಲ್ಲ.
ಜೋಡಿಯನ್ನು ಹೊಂದಿಸಿ, ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ
ಯಾವುದನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡೂ ಸಂರಚನೆಗಳನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಈಗಾಗಲೇ ಸರಿಯಾದ ಬದಿಯನ್ನು ಸಂಪಾದಿಸುವುದು ಕೆಲಸವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುತ್ತದೆ. ಕೆಳಗಿನ grep ಪ್ರತಿ ಫೈಲ್ ಯಾವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ; ವಿವರವಾದ ರನ್ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಆರಂಭದಲ್ಲಿ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಇರಿಸಿ, ಮುಂದಿನ ಬದಲಾವಣೆಯನ್ನು ತಿಳಿದ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
ಯಾವುದೇ ಬದಲಾವಣೆಯ ನಂತರ ಎರಡೂ ಪೀರ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಈ ಆಯ್ಕೆಗಳು ಪ್ರಾರಂಭದಲ್ಲಿ ಒಮ್ಮೆ ಓದಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಒಂದು ಬದಿಯನ್ನು ಮರುಲೋಡ್ ಮಾಡುವುದು ಹಳೆಯ ಅಧಿವೇಶನದ ಇಡೀ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಜೋಡಿಯನ್ನು ಅಸಂಗತವಾಗಿ ಬಿಡುತ್ತದೆ. ನಿಯೋಜನೆ ಈಗ ದಿಕ್ಕು ಸಂರಚಿಸದೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಒಂದು ಪೀರ್‌ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್ ಸೇರಿಸುವುದು ನೀವು ಪ್ರಾರಂಭಿಸಿದ ವೈಫಲ್ಯವನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ; ಒಂದೋ ಎರಡನ್ನೂ ಬಿಡಿ ಅಥವಾ ಎರಡನ್ನೂ ಸಂರಚಿಸಿ. ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ತುದಿ ಬದಲಿಸಿ ಮತ್ತು ಹಿಂದಿನ ಫೈಲ್ ಇರಿಸಿ, ರಿಗ್ರೆಷನ್ ಮರುನಿರ್ಮಾಣವಲ್ಲ, ಎರಡು ನಿಮಿಷಗಳ ಹಿಂಪಡೆಯುವಿಕೆಯಾಗಲಿ.
ಪ್ರತಿ ತುದಿಗೆ ಕಾರ್ಯವಿಧಾನ, ಕೀ ಫೈಲ್ ಮತ್ತು ದಿಕ್ಕನ್ನು ನಿಯೋಜನೆ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಎರಡು ಸಮಾನ ಫೈಲ್‌ಗಳನ್ನು ಓದಿ ಸಂಖ್ಯೆಗಳು ಪರಸ್ಪರ ಹೊಂದಿಕೆಯಾಗಬೇಕು ಎಂದು ಭಾವಿಸುತ್ತಾನೆ. ದಿಕ್ಕು ಸಮನ್ವಯ ವಿವರ, ಭದ್ರತಾ ಉನ್ನತೀಕರಣವಲ್ಲ: ಅದು ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ನ ಎರಡು ದಿಕ್ಕುಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ ಮತ್ತು ಬೇರೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.