ಎರಡು VPN ಪದರಗಳನ್ನು ಒಂದರ ಮೇಲೊಂದು ಇಡಬೇಕೇ? ಪರಿಶೀಲಿಸಲು ಮೂರು ಷರತ್ತುಗಳು

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

ವೀಕ್ಷಕನು ಏನನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾನೆ ಎಂದು ಬರೆಯಿರಿ

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

ಆದ್ದರಿಂದ ಉಪಯುಕ್ತ ಕಲಾಕೃತಿ ಸಮಯರೇಖೆ, ಪೆಟ್ಟಿಗೆಗಳ ರೇಖಾಚಿತ್ರವಲ್ಲ. ಪ್ರತಿ ಪದರಕ್ಕೂ ಅಂತಿಮ ಬಿಂದು, ಕೀಲಿಯ ಮಾಲೀಕ, ಗುರುತಿನ ಪರಿಶೀಲನೆ ಮತ್ತು ಊಹೆ ವಿಫಲವಾಗುವ ನಿರೀಕ್ಷಿತ ವರ್ಷವನ್ನು ಬರೆಯಿರಿ.

ನಿಮ್ಮದೇ ಹೇಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸುವ ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗ: ವೀಕ್ಷಕನು ಎಲ್ಲವನ್ನೂ ದಾಖಲಿಸುತ್ತಾನೆ ಮತ್ತು ಎಂದಿಗೂ ಬಿಟ್ಟುಕೊಡುವುದಿಲ್ಲ ಎಂದು ಊಹಿಸಿ. ಆ ಊಹೆಯ ಅಡಿಯಲ್ಲಿ, ವಿನ್ಯಾಸವು ಅಗತ್ಯವಿರುವ ಜೀವಿತಾವಧಿಯವರೆಗೆ ಪೇಲೋಡ್ ಅನ್ನು ಇನ್ನೂ ರಕ್ಷಿಸುತ್ತದೆಯೇ? ಉತ್ತರವು ವೀಕ್ಷಕನು ಸಂಚಾರವನ್ನು ಸಂಗ್ರಹಿಸದಿರಲು ಆಯ್ಕೆ ಮಾಡುವುದನ್ನು ಅವಲಂಬಿಸಿದರೆ, ವಿನ್ಯಾಸಕ್ಕೆ ಉತ್ತರವಿಲ್ಲ.

ಷರತ್ತು ಒಂದು: ಪದರಗಳು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆಯೇ?

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

ಇದನ್ನು ವಿನ್ಯಾಸದಿಂದ ಅಲ್ಲ, ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಯಿಂದ ಪರಿಶೀಲಿಸಿ. Linux ನಲ್ಲಿ, ip xfrm state ಪ್ರತಿ ಸುರಕ್ಷತಾ ಸಂಘ ಮತ್ತು ಅದರ ಅಂತ್ಯ ಬಿಂದುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಇದು ಪ್ರತಿ ಪದರವು ನಿಜವಾಗಿ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಷರತ್ತು ಎರಡು: ಕೀಲಿ ಸಾಮಗ್ರಿ ನಿಜವಾಗಿಯೂ ಸ್ವತಂತ್ರವೇ?

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

ಇಲ್ಲಿ ಹೈಬ್ರಿಡ್ ಕೀಲಿ ಸ್ಥಾಪನೆ ಸುರಂಗಗಳನ್ನು ಒಂದರ ಮೇಲೊಂದು ಇಡುವುದನ್ನು ಮೀರುತ್ತದೆ. IKEv2 ಒಂದೇ ಮಾತುಕತೆಯಲ್ಲಿ ಹಲವು ಕೀಲಿ ವಿನಿಮಯಗಳನ್ನು ಒಯ್ಯಬಲ್ಲದು, ಆದ್ದರಿಂದ ಶಾಸ್ತ್ರೀಯ ಗುಂಪು ಮತ್ತು ಪೋಸ್ಟ್-ಕ್ವಾಂಟಮ್ KEM ಎರಡೂ ಒಂದೇ ಸೆಷನ್ ಕೀಲಿಗಳನ್ನು ಪೋಷಿಸಬಹುದು, ಒಂದರ ಸುತ್ತ ಇನ್ನೊಂದನ್ನು ಸುತ್ತುವ ಬದಲು. ಫಲಿತಾಂಶವು ಎರಡೂ ರಹಸ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಕೀಲಿಗಳನ್ನು ಹೊಂದಿರುವ ಒಂದೇ ಸುರಕ್ಷತಾ ಸಂಘ, ಮತ್ತು ಆಕ್ರಮಣಕಾರನು ಎರಡನ್ನೂ ಮುರಿಯಬೇಕು. ಇದು ನಿಗದಿತ ಸಂಯೋಜನೆಯ ದಾಖಲಿತ ನಿರ್ಮಾಣ, ಎರಡು VPN ಉತ್ಪನ್ನಗಳ ಮನೆಮಾಡಿದ ರಾಶಿ ಅಲ್ಲ. strongSwan ನಲ್ಲಿ, swanctl --list-sas ಪ್ರತಿ SA ಗೆ ಸಮಾಲೋಚಿಸಿದ ಪ್ರಸ್ತಾಪವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಹೀಗೆ ನೀವು ಸಂರಚಿಸಿದ್ದನ್ನು ಅಲ್ಲ, ನಿಜವಾಗಿ ಏನು ಓಡಿತು ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸುತ್ತೀರಿ.

ಷರತ್ತು ಮೂರು: ಡೇಟಾ ಹೊರಗಿನ ಊಹೆಗಿಂತ ಹೆಚ್ಚು ಬದುಕುತ್ತದೆಯೇ?

ಇಪ್ಪತ್ತು ವರ್ಷ ನಿಲ್ಲಬೇಕಾದ ಪದರಕ್ಕೆ ಇಪ್ಪತ್ತು ವರ್ಷದ ವಾದ ಬೇಕು. ಈಗ ದಾಖಲಿಸಿ ನಂತರ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಅಗ್ಗ, ಮತ್ತು ಆದ್ದರಿಂದ ಶಾಸ್ತ್ರೀಯ ಹೊರಗಿನ ಪದರವನ್ನು ಬಲವಾದ ಯಾವುದೋ ಸುತ್ತಲಿನ ತಾತ್ಕಾಲಿಕ ಹೊದಿಕೆಯಾಗಿ ಪರಿಗಣಿಸಲಾಗದು.

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

ಉತ್ತರ ಇಲ್ಲ ಎಂದಾಗ ಬದಲಾಗಿ ಏನನ್ನು ನಿರ್ಮಿಸಬೇಕು

ಮೂರು ಷರತ್ತುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ವಿಫಲವಾದರೆ, ನೆಸ್ಟಿಂಗ್ ಬಿಟ್ಟು ಪ್ರಯತ್ನವನ್ನು ಜೀವಿತಾವಧಿ ಅಗತ್ಯವನ್ನು ನಿಜವಾಗಿ ಹೊತ್ತಿರುವ ಪದರಕ್ಕೆ ವ್ಯಯಿಸಿ. ನೀವು ಈಗಾಗಲೇ ಚಲಾಯಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಹೈಬ್ರಿಡ್ ಕೀಲಿ ವಿನಿಮಯವನ್ನು ಸಂರಚಿಸಿ, ಅನುಷ್ಠಾನವನ್ನು ನವೀಕೃತವಾಗಿಡಿ, ಮತ್ತು ನೀವು ಅವಲಂಬಿಸಿರುವ ಸಂಯೋಜನೆಯನ್ನು ಬರೆಯಿರಿ. ವಿನ್ಯಾಸ ದಾಖಲೆಯಲ್ಲಿ ML-KEM ಹೆಸರಿಸುವುದು ಸುರಕ್ಷತಾ ಗುಣವಲ್ಲ, ಮತ್ತು FIPS 203 ಕೀಲಿ-ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ನಿಮ್ಮ ಸುರಂಗವನ್ನಲ್ಲ.

ಎರಡನೇ ಪದರವು ನಿಜವಾಗಿ ತನ್ನ ಸ್ಥಾನವನ್ನು ಗಳಿಸುವ ಸ್ಥಳದಲ್ಲಿ, ಅದನ್ನು ಸಾಕ್ಷ್ಯವಾಗಿ ಅಲ್ಲ, ಆಳದಲ್ಲಿ ರಕ್ಷಣೆಯಾಗಿ ವಿವರಿಸಿ. ನಂತರ ಸಂಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಯಾವ ಅಂತ್ಯ ಬಿಂದು ಯಾವ ಕೀಲಿಯನ್ನು ಹೊಂದಿದೆ, ಪ್ರತಿ ಬದಿಯು ಯಾವ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಕನ್ಸೋಲ್ ಪ್ರವೇಶವಿರುವ ನಿರ್ವಾಹಕ ಏನನ್ನು ಓದಬಹುದು. ಆ ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ತಾಳಿಕೊಳ್ಳುವ ವಿನ್ಯಾಸವು ಹೆಚ್ಚುವರಿ ಪ್ರೊಸೆಸರ್‌ಗೆ ಅರ್ಹವಾಗಿದೆ. ತಾಳಿಕೊಳ್ಳದಿರುವುದು ಕೇವಲ ರೇಖಾಚಿತ್ರ.

ಬದಲಾವಣೆ ವಿಂಡೋದ ಮೊದಲು ಪ್ರಸ್ತುತ SA ಕೋಷ್ಟಕ ಮತ್ತು ಸಮಾಲೋಚಿಸಿದ ಪ್ರಸ್ತಾಪಗಳನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ನಂತರ ಅವನ್ನು ಮತ್ತೆ ಸೆರೆಹಿಡಿದು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಮುಖ್ಯವಾದ ಏಕೈಕ ಸಾಕ್ಷ್ಯ ಸಾಧನಗಳು ನಿಜವಾಗಿ ಒಪ್ಪಿಕೊಂಡದ್ದು.