IKEv2 NO_PROPOSAL_CHOSEN: ಯಾವ ಹಂತವು ಸೂಟ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಿತು?

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

ಮೊದಲು: ಯಾವ ವಿನಿಮಯ ತಿರಸ್ಕೃತವಾಯಿತು

IKEv2 ಎರಡು ರೀತಿಯ ಸಂಘಗಳ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ. IKE SA ಮಾತುಕತೆಯನ್ನೇ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು CHILD SA ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಪ್ರಸ್ತಾವ ಸಮೂಹವಿದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಒಂದೇ ಅಧಿಸೂಚನೆಯೊಂದಿಗೆ ವಿಫಲವಾಗಬಹುದು. ಆರಂಭಿಕ IKE ಮಾತುಕತೆಯ ಸಮಯದ ತಿರಸ್ಕಾರ ಮತ್ತು CHILD ಮಾತುಕತೆಯ ಸಮಯದ ತಿರಸ್ಕಾರಕ್ಕೆ ಬೇರೆ ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆ ಬೇಕು, ಮತ್ತು ಲಾಗ್ ಸಾಮಾನ್ಯವಾಗಿ ಅಧಿಸೂಚನೆಯ ಒಂದೆರಡು ಸಾಲು ಮೇಲೆ ವಿನಿಮಯವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಆ ಎರಡು ಸಾಲುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ, ಇಲ್ಲದಿದ್ದರೆ ತಪ್ಪು ಪ್ರಸ್ತಾವ ಪಟ್ಟಿಯನ್ನು ಸಂಪಾದಿಸುತ್ತೀರಿ.

ಕೇವಲ ಅಧಿಸೂಚನೆ ವಿನಿಮಯವನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ. ಅದರ ಮೇಲಿನ ಸಾಲು ಮಾತುಕತೆ ನಡೆಯುತ್ತಿರುವ SA ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಹೆಸರು ಪರಿಶೀಲಿಸಬೇಕಾದ ಪ್ರಸ್ತಾವ ಪಟ್ಟಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಸಂಪೂರ್ಣ ಸೂಟ್ಗಳನ್ನು ಹೋಲಿಸಿ, ಪ್ರತ್ಯೇಕ ಕೀವರ್ಡ್ಗಳನ್ನಲ್ಲ

ಪ್ರಸ್ತಾವವು ಒಂದು ಸಂಯೋಜನೆ: ಎನ್ಕ್ರಿಪ್ಶನ್ ಅಲ್ಗಾರಿದಮ್, ಸಮಗ್ರತೆ ಅಥವಾ AEAD, ಕೀಲಿ-ವಿನಿಮಯ ಗುಂಪು, ಮತ್ತು ಯಾವುದೇ ಸೂಡೋ-ಯಾದೃಚ್ಛಿಕ ಕಾರ್ಯ. ಕೇವಲ ಎನ್ಕ್ರಿಪ್ಶನ್ ಹೆಸರನ್ನು ಹೋಲಿಸುವುದು ಸಾಮಾನ್ಯ ತಪ್ಪು, ಏಕೆಂದರೆ ಇಬ್ಬರು ಸಹಚರರು AES-256 ನಲ್ಲಿ ಒಪ್ಪಿ ಕೂಡ SHA-1 ಮತ್ತು SHA-256 ವಿಷಯದಲ್ಲಿ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಬಹುದು. ವಿಫಲ ಹಂತದಲ್ಲಿ ಪ್ರಸ್ತಾವಿಸಿದ ಮತ್ತು ಅನುಮತಿಸಲಾದ ಸೂಟ್ಗಳನ್ನು ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ನಂತರ ಖಾಲಿ ಛೇದನವನ್ನು ಹುಡುಕಿ.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

IKE ಸೂಟ್ ಮತ್ತು ESP ಸೂಟ್ ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು

IKE ಪ್ರಸ್ತಾವವನ್ನು ಸಂಪಾದಿಸುವುದರಿಂದ ತಿರಸ್ಕೃತ CHILD ಪ್ರಸ್ತಾವ ಸರಿಯಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಇದಕ್ಕೆ ವಿರುದ್ಧವೂ ನಿಜ. strongSwan ನಲ್ಲಿ ಇವು ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಸುಮಾರು IKE SA ಗೆ proposals = aes256-sha256-modp2048 ಮತ್ತು CHILD SA ಗೆ ಪ್ರತ್ಯೇಕ ESP ಪಟ್ಟಿ. ವಿಫಲ ವಿನಿಮಯಕ್ಕೆ ಹೊಂದುವ ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸಿ, ನಂತರ ಸರಿಪಡಿಸುವಿಕೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ಭಾವಿಸದೆ ಲಾಗ್ ಅನ್ನು ಮತ್ತೆ ಓದಿ.

CHILD SA ಗೆ ಸಂಬಂಧಿಸಿದ ಸೆಟ್ಟಿಂಗ್ ESP ಪ್ರಸ್ತಾವ ಪಟ್ಟಿ, IKE ಪಟ್ಟಿಯಲ್ಲ. ಅದರೊಳಗೆ IKE ಸಾಲನ್ನು ನಕಲಿಸುವುದರಿಂದ ಪಾರ್ಸ್ ಆಗುವ ಆದರೆ ತಪ್ಪು ವಸ್ತುವಿನ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸುವ ಸಂರಚನೆ ಉಂಟಾಗುತ್ತದೆ.

ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸುರಂಗ ಕೀಲಿ ನವೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ

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

ipsec statusall ಪ್ರತಿ ಸಂಘ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಮಾತುಕತೆಯಾದ ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಆ ಔಟ್ಪುಟ್ ಯಾವ ಪಟ್ಟಿ ಬಳಸಲಾಯಿತು ಎಂದು ಖಚಿತಪಡಿಸುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ, ಮತ್ತು ಸಂರಚನಾ ದೋಷವನ್ನು ಎಂದಿಗೂ ಮರುಮಾತುಕತೆ ಮಾಡದ ಹಳೆಯ ಸುರಂಗದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ipsec statusall | grep -E "IKE:|ESP:"

ಛೇದನವನ್ನು ಆರಿಸಿ, ನಂತರ ಎರಡೂ ಹಂತಗಳನ್ನು ಖಚಿತಪಡಿಸಿ

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

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