OpenVPN ನಿಯಂತ್ರಣ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಟ್ರೇಸ್ ಮಾಡುವುದು: TLS ಮೊದಲು tls-auth

tls-auth ವೈಫಲ್ಯವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಸ್ಯೆ ಎಂದು ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಅದು ಎಂದೂ ಹಾಗಿರಲಿಲ್ಲ. ಯಾವುದೇ TLS ಸಂಸ್ಕರಣೆ ಆರಂಭವಾಗುವ ಮೊದಲು ನಿಯಂತ್ರಣ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ HMAC ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊಂದಿಕೆಯಾಗದ ಕೀ ಅಥವಾ ದಿಕ್ಕು ಪ್ರಮಾಣಪತ್ರ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ಮತ್ತು ಎರಡು ಪದರ ಮೊದಲೇ ನಿರ್ಧರಿಸಲ್ಪಡುವ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಹೊದಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕ ವಸ್ತುವಾಗಿ ಪರಿಗಣಿಸಿದರೆ ರೋಗನಿರ್ಣಯ ಚಿಕ್ಕದಾಗುತ್ತದೆ: ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಿ, ಪರಿಶೀಲನೆ ಬೇಗ ನಡೆಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಎರಡೂ ತುದಿಗಳು ಒಪ್ಪಬೇಕಾದ ಮೂರು ವಿಷಯಗಳನ್ನು ಹೋಲಿಸಿ.

ಹೊದಿಕೆಯನ್ನು ನಿರ್ಮಾಣವಾಗುವ ಕ್ರಮದಲ್ಲೇ ಓದಿ

ನಿಯಂತ್ರಣ ಪ್ಯಾಕೆಟ್ ಸೆಷನ್ ಗುರುತು, ಐಚ್ಛಿಕ tls-auth HMAC, ಪುನರಾವರ್ತನೆ ಮತ್ತು ಸ್ವೀಕೃತಿ ಮಾಹಿತಿ, ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಸಂದೇಶ ಗುರುತನ್ನು ಹೊತ್ತುಕೊಂಡಿರುತ್ತದೆ, ನಂತರ ಸಂದೇಶ ಪ್ರಕಾರದ ಪೇಲೋಡ್ ಬರುತ್ತದೆ. ಸಂದೇಶ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂದೇಶವಾದಾಗ, ಪೇಲೋಡ್ TLS ಸೈಫರ್‌ಟೆಕ್ಸ್ಟ್ ಆಗಿರುತ್ತದೆ. ಸಂಬಂಧ ಇಷ್ಟೇ: TLS ಸಾಮಗ್ರಿ ಹೊದಿಕೆ ಈಗಾಗಲೇ ರಕ್ಷಿಸುವ ಸಂದೇಶದ ಒಳಗೆ ಸಾಗುತ್ತದೆ. ನೋಡಿ OpenVPN ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ ಉಲ್ಲೇಖ ಇದು ನಿಯಂತ್ರಣ ಚಾನಲ್‌ನ ಕ್ಷೇತ್ರಗಳನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

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

ಈ ಗುಂಪನ್ನು ಪರಿಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಇರಿಸಿ. ಇದು ಬೈಟ್ ಕ್ರಮದ ರೇಖಾಚಿತ್ರವಲ್ಲ, ಮತ್ತು ಟ್ಯಾಗ್ ಲೆಕ್ಕಹಾಕಲು ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ HMAC ಗೆ ಪ್ರವೇಶಿಸುವ ಕ್ಷೇತ್ರಗಳು ಅನುಷ್ಠಾನ, ಆವೃತ್ತಿ ಮತ್ತು ಮೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿವೆ.

ಪರಿಶೀಲನೆ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಿಂತ ಮೊದಲು ನಡೆಯುತ್ತದೆ ಎಂದು ತೋರಿಸಿ

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

ಡೀಮನ್‌ನ ವಾಚಾಲತೆ ಹೆಚ್ಚಿಸಿ ಮತ್ತು tun ಸಾಧನದ ಬದಲು ನಿಯಂತ್ರಣ ಚಾನಲ್ ಗಮನಿಸಿ:

openvpn --config /etc/openvpn/server.conf --verb 6

ನೀವು ಹುಡುಕುತ್ತಿರುವುದು ಪ್ಯಾಕೆಟ್ ಮಟ್ಟದಲ್ಲಿ ವರದಿಯಾಗುವ ನಿಯಂತ್ರಣ ಚಾನಲ್ HMAC ಪರಿಶೀಲನಾ ವೈಫಲ್ಯ, ಯಾವುದೇ TLS ಎಚ್ಚರಿಕೆಗಿಂತ ಮೊದಲು. ಲಾಗ್‌ನಲ್ಲಿ TLS ಎಚ್ಚರಿಕೆ ಎಂದರೆ ಹೊದಿಕೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ವೈಫಲ್ಯ ಒಳಕ್ಕೆ ಸರಿದಿದೆ, ಅದು ಬೇರೆ ಪರಿಹಾರದ ಬೇರೆ ತನಿಖೆ.

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

ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಕೀ, ದಿಕ್ಕು ಮತ್ತು digest ಹೊಂದಿಸಿ

ಮೂರು ಮೌಲ್ಯಗಳು ಒಪ್ಪಬೇಕು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಫೈಲ್. ಸ್ಥಿರ ಕೀಯ ವಿಷಯ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರಬೇಕು, ದಿಕ್ಕು ವಿರುದ್ಧವಾಗಿರಬೇಕು, ಮತ್ತು HMAC ಗೆ ಬಳಸುವ digest ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಕೀ ಸಾಮಗ್ರಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಉಲ್ಟಾ ದಿಕ್ಕು ಹಾಳಾದ ಫೈಲ್‌ಗಿಂತ ಹೆಚ್ಚು ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

ಹಂಚಿದ ರಹಸ್ಯವನ್ನು ಸಂಪಾದಕದ ಬದಲು ಸಾಧನದಿಂದ ರಚಿಸಿ, ಮತ್ತು ಅನುಮತಿಗಳನ್ನು ಬಿಗಿಯಾಗಿ ಇರಿಸಿ:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

ಟ್ಯಾಗ್ ಅನ್ನು ನಿಜವಾದ ಸ್ವರೂಪದಿಂದ ಮಾತ್ರ ಮರುಸೃಷ್ಟಿಸಿ

ಬೈಟ್-ನಿಖರ ಮರುಸೃಷ್ಟಿ VPN ನಡೆಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಕೆಲಸ, ಮತ್ತು ಅದು ನಿಜವಾದ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಪ್ಯಾಕೆಟ್ ನಿರ್ಮಿಸಿದ ಅನುಷ್ಠಾನ ಮತ್ತು ಆವೃತ್ತಿ, ಆಯ್ಕೆ ಮಾಡಿದ digest, ದಿಕ್ಕು, ಮತ್ತು ಸೆಷನ್ ಗುರುತು ಹಾಗೂ ಸ್ವೀಕೃತಿ ಶ್ರೇಣಿ ಸೇರಿದಂತೆ ನಿಜವಾದ ಬೈಟ್‌ಗಳು. ಕ್ಷೇತ್ರ ಪಟ್ಟಿಯ ಪಠ್ಯ ನಿರೂಪಣೆ ಆ ಬೈಟ್‌ಗಳಲ್ಲ.

ಟ್ಯಾಗ್‌ನ ಉದ್ದ digest ನಿಂದ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಶ್ಚಿತ ಉದ್ದದ ಊಹೆ ಯಾರಾದರೂ ಅದನ್ನು ಬದಲಿಸಿದ ಕ್ಷಣದಲ್ಲಿ ಒಡೆಯುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಷ್ಠಾನ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಹ್ಯಾಶ್ ಮಾಡಿ, ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ನ ಕೋಷ್ಟಕ ಪ್ರಸ್ತುತಪಡಿಸುವ ರೀತಿಯಲ್ಲಿ ಅಲ್ಲ, ಮತ್ತು ಕೈಯಿಂದ ಪಡೆದ ನಿರೀಕ್ಷೆಯ ಬದಲು ಅದೇ ಸಹಭಾಗಿಯಿಂದ ತೆಗೆದ ಸೆರೆಹಿಡಿಯುವಿಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಈ ಅಭ್ಯಾಸವನ್ನು ಉತ್ಪಾದನಾ ಪ್ರೊಫೈಲ್‌ಗಳಿಂದ ದೂರವಿಡಿ. ಟ್ಯಾಗ್ ಮರುಸೃಷ್ಟಿಸುವಲ್ಲಿ ನಿಯೋಜನೆ ರಕ್ಷಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕೇ ಎಂದು ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

ರಕ್ಷಣೆ ತೆಗೆಯದೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಹಿಂಪಡೆಯಿರಿ

ಪ್ರಲೋಭನೆಯ ಪರೀಕ್ಷೆ ಎಂದರೆ tls-auth ಅನ್ನು ಅಳಿಸಿ, ಸಂಪರ್ಕ ಯಶಸ್ವಿಯಾಗುವುದನ್ನು ನೋಡಿ, ಕೀ ತಪ್ಪಾಗಿತ್ತು ಎಂದು ತೀರ್ಮಾನಿಸುವುದು. ಆ ಉತ್ತರ ನಿಮಗೆ ರಕ್ಷಣೆಯನ್ನು ವೆಚ್ಚ ಮಾಡಿಸುತ್ತದೆ ಮತ್ತು ಮೂರರಲ್ಲಿ ಯಾವ ಮೌಲ್ಯ ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ ಎಂದು ಏನೂ ಕಲಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ ಸರ್ವರ್ ಕಡೆಯಿಂದ ಅನುಮೋದಿತ ಹೊಂದಿಕೆಯ ಸಂರಚನೆಯನ್ನು ಪಡೆದು ಅದರೊಂದಿಗೆ ಹೋಲಿಸಿ.

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

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