OpenVPN ಡೈಜೆಸ್ಟ್‌ಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಚರ್ಚೆ ತಪ್ಪು ಪ್ಯಾಕೆಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. auth SHA256 ಅನ್ನು “SHA256 ನೀಡುವ ಪೀರ್‌ಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಿ” ಎಂದು ಓದುವುದು ಮೊದಲು ಮರೆಯಬೇಕಾದ ವಿಷಯ. ಆಯ್ಕೆಯು ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಡೈಜೆಸ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಯಾವುವು ಎಂಬುದು ಚಾನೆಲ್ ಮತ್ತು ಆ ಚಾನೆಲ್ AEAD ಆಗಿದೆಯೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಕೆಳಗಿನ ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ನೋಡಿ; ಪ್ರತಿಯೊಂದೂ ನಿಮ್ಮ ನಿಯೋಜನೆಯಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ನ ಅರ್ಥವನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ.

ಸೆಟ್ಟಿಂಗ್ ರಕ್ಷಿಸಬೇಕಾದ ಚಾನೆಲ್ ಅನ್ನು ಹೆಸರಿಸಿ

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

ಕೆಳಗಿನ ಕೋಷ್ಟಕವು ಅದೇ ಆಯ್ಕೆ ಪ್ರತಿ ಸಂದರ್ಭದಲ್ಲಿ ಹೇಗೆ ಇಳಿಯುತ್ತದೆ ಎಂಬುದರ ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿ.

ContextWhat the auth digest does
Data channel without AEADSelects the HMAC digest that authenticates each data packet
Data channel with AEAD, such as GCMUnused for the data channel; the cipher authenticates its own packets
Control channel protected by tls-authSelects the HMAC digest for that protection, even when data is AEAD

ಅದನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ಡೇಟಾ ಚಾನೆಲ್ AEAD ಆಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಸಮಾಲೋಚಿಸಿದ ಡೇಟಾ ಸೈಫರ್ AES-GCM ಅಥವಾ CHACHA20-POLY1305 ಆಗಿದ್ದರೆ, ಡೇಟಾ ಚಾನೆಲ್ ತನ್ನನ್ನು ತಾನೇ ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಡೈಜೆಸ್ಟ್ ನೀವು ಊಹಿಸುವ ಕೆಲಸವನ್ನು ಮಾಡುವುದಿಲ್ಲ. ಎರಡೂ AEAD ರಚನೆಗಳು, ಆದ್ದರಿಂದ ಸಮಗ್ರತೆ ಪೇಲೋಡ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಅದೇ ಕ್ರಿಯೆಯಿಂದ ಉತ್ಪತ್ತಿಯಾಗುತ್ತದೆ. ಇದು ಅವನತಿ ಅಲ್ಲ, ಆದರೆ “ಪ್ರತಿ ಡೇಟಾ ಪ್ಯಾಕೆಟ್ HMAC-SHA256” ಎಂದು ಸಮರ್ಥಿಸಲಾದ ನೀತಿ ಆ ಟನೆಲ್‌ನಲ್ಲಿ ವಾಸ್ತವವಾಗಿ ತಪ್ಪು ಎಂದು ಅರ್ಥ. ನೀತಿಯನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ಸರ್ವರ್ ಲಾಗ್ ಅಥವಾ ಕ್ಲೈಂಟ್ ಸ್ಥಿತಿ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಸಮಾಲೋಚಿತ ಮೌಲ್ಯವನ್ನು ದೃಢೀಕರಿಸಿ.

ಪ್ರೊಫೈಲ್‌ನ ಪಟ್ಟಿಗಿಂತ ನಿಜವಾಗಿ ಸಮಾಲೋಚಿಸಿದ ಸೈಫರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸಮಾಲೋಚನೆ ಸಮುಚ್ಚಯದ ಇನ್ನೊಂದು ಸದಸ್ಯನ ಮೇಲೆ ಬೀಳಬಹುದು. data-ciphers AES-256-GCM:AES-128-GCM ಸಮಾಲೋಚನಾ ಪಟ್ಟಿ, ಮತ್ತು ಎರಡೂ ನಮೂದುಗಳು AEAD, ಆದ್ದರಿಂದ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪೇಲೋಡ್ ರಕ್ಷಣೆಗೆ auth ಡೈಜೆಸ್ಟ್ ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ.

ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ರಕ್ಷಣೆಯನ್ನು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರವಾಗಿ ಪರಿಗಣಿಸಿ

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

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

auth ಅನ್ನು ಸೈಫರ್ ಸಮಾಲೋಚನೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

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

ಡೈಜೆಸ್ಟ್ ಬದಲಾವಣೆಯ ನಂತರ ಪೀರ್ ಸಂಪರ್ಕಿಸಲು ನಿರಾಕರಿಸಿದರೆ, ಕಾರಣ ಸಾಮಾನ್ಯವಾಗಿ ಉಳಿದ ಎರಡು ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಅಸಾಮರಸ್ಯ. ಯಾವುದನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳನ್ನು ಓದಿ.

ನೀತಿಯನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾನ್ಫಿಗ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ

ಫ್ಲೀಟ್-ಮಟ್ಟದ ಹೇಳಿಕೆಯು ಅನುಮತಿಸಲಾದ ಡೇಟಾ-ಚಾನೆಲ್ ವಿಧಾನಗಳನ್ನು ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಿದ ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ರಕ್ಷಣೆಯನ್ನು ಒಂದೇ ವಾಕ್ಯದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸಬೇಕು. ಆ ವಾಕ್ಯವು ಪರೀಕ್ಷಿಸಬಹುದಾದದ್ದು; “ನಾವು SHA256 ಬಳಸುತ್ತೇವೆ” ಅಲ್ಲ. ನಂತರ ಅದನ್ನು ಸಂಗ್ರಹದಲ್ಲಿನ ಟೆಂಪ್ಲೇಟ್‌ಗೆ ಅಲ್ಲ, ಪರಿಣಾಮಕಾರಿ ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್‌ಗಳಿಗೆ ಹೋಲಿಸಿ.

ಪ್ರತಿ ಟನೆಲ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸಮಾಲೋಚಿಸಿತು ಮತ್ತು ಯಾವ ಕಾರ್ಯವಿಧಾನ ಅದರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ದೃಢೀಕರಿಸಿತು ಎಂದು ದಾಖಲಿಸಿ ಮುಗಿಸಿ. ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಕಾಣುವ auth ಸಾಲು ಕಾನ್ಫಿಗರೇಶನ್ ಉದ್ದೇಶದ ಸಾಕ್ಷಿ ಮಾತ್ರ, ಮತ್ತು ಉದ್ದೇಶ ಪರಿಶೀಲನೆಯ ಅಗ್ಗದ ಭಾಗ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು