DH ಫೈಲ್ ಅಥವಾ tls-auth ಕೀ? ಎರಡು OpenVPN ಫೈಲ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು

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

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

ಫೈಲ್ ಹೆಸರಿಗಿಂತ ಮೊದಲು ಲೇಬಲ್ ಓದಿ

ಫೈಲ್‌ನ ಮೊದಲ ಸಾಲು ಅದರ ಹೆಸರಿಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿ ನೀಡುತ್ತದೆ, ಏಕೆಂದರೆ ಹೆಸರು ಮಾನವ ಸಂಪ್ರದಾಯ ಮತ್ತು ಲೇಬಲ್ ಅನ್ನು ಸಾಧನ ಉತ್ಪಾದಿಸುತ್ತದೆ. Diffie-Hellman ನಿಯತಾಂಕಗಳು BEGIN DH PARAMETERS ಎಂಬ PEM ಲೇಬಲ್ ಹೊಂದಿರುತ್ತವೆ. OpenVPN ಸ್ಥಿರ ಕೀ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ರಚನೆ, ಅದರದೇ ಶೀರ್ಷಿಕೆ ಮತ್ತು ಹೆಕ್ಸ್ ಪೇಲೋಡ್ ಇದೆ.

ಮರುನಾಮಕರಣ ಯಾವುದನ್ನೂ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ. ta.key ಎಂಬ ಹೆಸರಿನ ನಿಯತಾಂಕ ಫೈಲ್ ಇನ್ನೂ ನಿಯತಾಂಕಗಳೇ, ಮತ್ತು dh.pem ಎಂಬ ಹೆಸರಿನ ಸ್ಥಿರ ಕೀ ಇನ್ನೂ ಸ್ಥಿರ ಕೀಯೇ; ಪಾರ್ಸರ್ ವಿಷಯವನ್ನು ಓದಿ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ. ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ:

head -n 1 dh.pem
head -n 1 ta.key

ಯಾವ ಫೈಲ್ ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

ಮೊದಲ ಷರತ್ತು ವಿನಿಮಯ. ಸೀಮಿತ ಕ್ಷೇತ್ರದ Diffie-Hellman ಕೈಹಿಡಿತಕ್ಕೆ ಒಂದು ಗುಂಪು ಬೇಕು, ಮತ್ತು dh ಸೂಚನೆ ಎಂಬುದು ಸರ್ವರ್ ಅದಕ್ಕೆ ನಿಯತಾಂಕಗಳನ್ನು ಹೆಸರಿಸುವ ಸ್ಥಳ. ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರದ ಕೈಹಿಡಿತಕ್ಕೆ ಆ ಫೈಲ್ ಬೇಕೇ ಇಲ್ಲ, ಏಕೆಂದರೆ ವಕ್ರವೇ ನಿಯತಾಂಕ ಸಮೂಹ. ನಿಮ್ಮ ಸರ್ವರ್ ಕೇವಲ ECDHE ಸೂಟ್‌ಗಳನ್ನು ಮಾತುಕತೆ ನಡೆಸಿದರೆ, DH ಫೈಲ್ ಹೆಚ್ಚುವರಿ ಶಕ್ತಿಯಲ್ಲ, ಸತ್ತ ಭಾರ.

ಎರಡನೇ ಷರತ್ತು ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ದೃಢೀಕರಣ, ತನ್ನದೇ ಸಾಮಗ್ರಿ ಇರುವ ಪ್ರತ್ಯೇಕ ವೈಶಿಷ್ಟ್ಯ. tls-auth ಫೈಲ್ ಎರಡೂ ಪಕ್ಷಗಳು ಹೊಂದಿರುವ ಹಂಚಿಕೆಯ ಸ್ಥಿರ ಕೀ, ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಸಹಿ ಹಾಕಲು ಬಳಸಲಾಗುತ್ತದೆ, ಇದರಿಂದ ದೃಢೀಕರಿಸದ ಪಕ್ಷ ಕೈಹಿಡಿತವನ್ನೂ ಪೂರ್ಣಗೊಳಿಸಲಾರದು. ನೀವು ಸೀಮಿತ ಕ್ಷೇತ್ರದ DH ಬಳಸಿದರೂ ಬಳಸದಿದ್ದರೂ ಅದು ಇರುತ್ತದೆ, ಮತ್ತು ಗುಂಪು ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಅದಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲ.

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

ಪ್ರತಿ ಪಾತ್ರಕ್ಕೂ ಸರಿಯಾದ ಸಾಮಗ್ರಿ ಉತ್ಪಾದಿಸಿ

ಸೂಚನೆ ನಿರೀಕ್ಷಿಸುವ ಸ್ವರೂಪವನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಧನವನ್ನು ಬಳಸಿ, ಅವುಗಳ ನಡುವೆ ಪರಿವರ್ತಿಸುವ ಬದಲು. OpenVPN 2.6 ನಲ್ಲಿ ಹಂಚಿಕೆಯ ಕೀಗೆ ಜನರೇಟರ್‌ನ ಟೈಪ್ ಮಾಡಿದ ರೂಪ ಉದ್ದೇಶವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ.

openvpn --genkey tls-auth ta.key

ಆ ಆಜ್ಞೆ ಹೊಸ ರಹಸ್ಯ ಸಾಮಗ್ರಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಅದು ಇರುವ ಕೀಯನ್ನು ದುರಸ್ತಿ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಮತ್ತೆ ಚಲಾಯಿಸಿದರೆ ಇತರ ಪಕ್ಷಗಳ ಬಳಿ ಇಲ್ಲದ ಬೇರೆ ಕೀ ಸಿಗುತ್ತದೆ. ಉತ್ಪನ್ನವಾದ ಫೈಲ್ ಅನ್ನು ಅದು ಬೇಕಾದ ಪಕ್ಷಗಳಿಗೆ ಯಾವುದೇ ಹಂಚಿಕೆಯ ರಹಸ್ಯಕ್ಕೆ ಬಳಸುವ ಮಾರ್ಗದ ಮೂಲಕ ನಕಲಿಸಿ, ಮತ್ತು ದಿಕ್ಕಿನ ಸಂಪ್ರದಾಯವನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿ: tls-auth ನಲ್ಲಿ ಒಂದು ಬದಿ key-direction 0 ಮತ್ತು ಇನ್ನೊಂದು key-direction 1 ಬಳಸುತ್ತದೆ.

DH ನಿಯತಾಂಕಗಳು ಬೇಕಾದಾಗ ನಿಯತಾಂಕ ಉತ್ಪಾದನೆಯಿಂದ ಬರುತ್ತವೆ, ಕೀ ಜನರೇಟರ್‌ನಿಂದ ಅಲ್ಲ, ಮತ್ತು ಫಲಿತಾಂಶ ಸಾರ್ವಜನಿಕವಾದರೂ ಅವುಗಳ ಮೂಲ ಮುಖ್ಯ. ಅಜ್ಞಾತ ಮೂಲದಿಂದ ಪಡೆದ ಗುಂಪು ಸಾರ್ವಜನಿಕವಾಗಿರುವುದರಿಂದ ನಂಬಲರ್ಹವಾಗುವುದಿಲ್ಲ; ಅದು ಇನ್ನೂ ನಿಮ್ಮ ಪಕ್ಷಗಳು ಒಪ್ಪುವ ಗುಂಪಾಗಿರಬೇಕು ಮತ್ತು ಅದರ ಗಾತ್ರ ಅಥವಾ ರಚನೆಯಿಂದ ದುರ್ಬಲಗೊಳ್ಳದಿರಬೇಕು.

dh none ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಏನು ಮಾಡುವುದಿಲ್ಲ

dh none ಸಂಕುಚಿತ ಅರ್ಥದ ನಿಜವಾದ ಸೂಚನೆ: ಯಾವುದೇ ಸೀಮಿತ-ಕ್ಷೇತ್ರ ನಿಯತಾಂಕ ಫೈಲ್ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕೈಹಿಡಿತ ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರದ Diffie-Hellman ಬಳಸುತ್ತದೆ. ಇದು ಏನನ್ನಾದರೂ ದುರ್ಬಲಗೊಳಿಸುವ ಅರ್ಥದಲ್ಲಿ “DH ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡಿ” ಎಂಬ ಸಂಕ್ಷಿಪ್ತ ರೂಪವಲ್ಲ, ಮತ್ತು OpenVPN ಗೆ ಬೇರೆ ಫೈಲ್ ಅನ್ನು ಪರ್ಯಾಯವಾಗಿ ಸ್ವೀಕರಿಸಲು ಖಂಡಿತವಾಗಿಯೂ ಹೇಳುವುದಿಲ್ಲ.

ತಪ್ಪಾಗಿ ಓದುವುದರಿಂದ ಎರಡು ತಪ್ಪುಗಳು ಬರುತ್ತವೆ. ಮೊದಲನೆಯದು dh none tls-auth ನ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು, ಆದರೆ ಎರಡೂ ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. ಎರಡನೆಯದು ಕೇವಲ-ವಕ್ರ ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ ಹಳೆಯ dh ಸಾಲನ್ನು ಇಟ್ಟುಕೊಂಡು ನಂತರ ಸರ್ವರ್ ನಿಜವಾಗಿ ಯಾವ ಫೈಲ್ ಬಳಸುತ್ತದೆ ಎಂದು ಯೋಚಿಸುವುದು; ಸೂಚನೆ ಇದ್ದರೆ ಫೈಲ್ ಓದಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿನ ಮುರಿದ ಮಾರ್ಗವು ಮಾತುಕತೆಯಾಗುವ ವಿನಿಮಯಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣದಿಂದ ಪ್ರಾರಂಭವನ್ನು ವಿಫಲಗೊಳಿಸುತ್ತದೆ.

ತಪ್ಪು ಫೈಲ್ ಈಗಾಗಲೇ ನಿಯೋಜಿಸಲಾಗಿದ್ದರೆ

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

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

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