IKEv2 ಒಂದೇ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅಲ್ಲ: ಮೊದಲು IKE SA, ನಂತರ ದೃಢೀಕರಣ, ನಂತರ CHILD SA
ಗೇಟ್ವೇಯ ಪ್ರತಿಕ್ರಿಯೆ ತಲುಪುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಗುರುತನ್ನು ಅಲ್ಲ. IKE_SA_INIT, IKE_AUTH ಮತ್ತು ಮೊದಲ CHILD SA ಅನ್ನು ಅನುಸರಿಸಿ, ನಂತರ ಸಂಚಾರ ಹರಿಯುವ ಮೊದಲು ಏನು ನಿಜವಾಗಿರಬೇಕೆಂದು ಪರಿಶೀಲಿಸಿ.
IKEv2 ಸಂಪರ್ಕವು ನಿಮ್ಮ ಸಂಚಾರ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ಮುಗಿಯುವ ಒಂದೇ ವಿನಿಮಯ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು. ವಾಸ್ತವವಾಗಿ ಕನಿಷ್ಠ ಎರಡು ಇವೆ, ಮತ್ತು ಮೊದಲನೆಯದು ಯಾರನ್ನೂ ದೃಢೀಕರಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಪಕ್ಷಗಳು ನಿಯಂತ್ರಣ ಸಂದೇಶಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ನಿಯತಾಂಕಗಳ ಮೇಲೆ ಒಪ್ಪಿ, ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರವೇ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುವ ಸ್ಥಿತಿಯನ್ನು ಸಂಧಾನ ಮಾಡುತ್ತವೆ. ಈ ಕ್ರಮವೇ ಜನರು ಪದೇ ಪದೇ ವರದಿ ಮಾಡುವ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಗೇಟ್ವೇ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎನ್ನುತ್ತದೆ, ಆದರೆ ಖಾಸಗಿ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಸಮಯ ಮೀರುತ್ತದೆ. ಪ್ರತಿ ಹಂತವು ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರ ಏನು ನಿಜವಾಗಿರಬೇಕು ಎಂಬುದು ಇಲ್ಲಿದೆ.
ಪುರಾಣ: ಗೇಟ್ವೇ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ ನೀವು ಸಂಪರ್ಕಗೊಂಡಿದ್ದೀರಿ
ಮೊದಲ ಸಂದೇಶಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆ ತುದಿ ಬಿಂದುವು ತಲುಪಲು ಸಾಧ್ಯ ಮತ್ತು ಮಾತನಾಡಲು ಸಿದ್ಧ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಖಾತೆ ಸ್ವೀಕರಿಸಲಾಗಿದೆ, ಪ್ರಮಾಣಪತ್ರ ಸರಪಳಿ ಮಾನ್ಯವಾಗಿದೆ, ಅಥವಾ ಯಾವುದೇ ಡೇಟಾ ನೀತಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಆ ವೈಫಲ್ಯಗಳು ನಂತರ ಸಂಭವಿಸಿ ಬೇರೆ ಲಕ್ಷಣಗಳನ್ನು ನೀಡುತ್ತವೆ. ಪ್ರಮಾಣಪತ್ರ ತಿರಸ್ಕಾರ ಅಥವಾ EAP ವೈಫಲ್ಯವು ಮೊದಲ ವಿನಿಮಯ ಈಗಾಗಲೇ ಯಶಸ್ವಿಯಾದ ನಂತರ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ UDP 500 ಗೆ ping ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಹಸಿರು ಚಿಹ್ನೆ ತುಂಬಾ ಕಡಿಮೆ ಹೇಳುತ್ತವೆ.
IKE_SA_INIT: ಗುರುತಿನ ಬಗ್ಗೆ ಅಲ್ಲ, ನಿಯತಾಂಕಗಳ ಬಗ್ಗೆ ಒಪ್ಪಿಗೆ
ಮೊದಲ ವಿನಿಮಯವು IKE ಭದ್ರತಾ ಸಂಘದ ಪ್ರಸ್ತಾಪಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ: ಎನ್ಕ್ರಿಪ್ಶನ್ ಮತ್ತು ಸಮಗ್ರತೆ ಅಲ್ಗಾರಿದಮ್ಗಳು, ಸೂಡೋ-ಯಾದೃಚ್ಛಿಕ ಕಾರ್ಯ ಮತ್ತು Diffie-Hellman ಗುಂಪು. ಪಕ್ಷಗಳು nonce ಗಳನ್ನೂ ವಿನಿಮಯ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ಬದಿಯೂ ಆ ಮೌಲ್ಯಗಳು ಉತ್ಪಾದಿಸುವ ಹಂಚಿದ ರಹಸ್ಯದಿಂದ IKE SA ಗಾಗಿ ಕೀ ಸಾಮಗ್ರಿಯನ್ನು ಪಡೆಯುತ್ತದೆ. ಈ ವಿನಿಮಯದಲ್ಲಿ ಯಾವುದೂ ಇನ್ನೊಂದು ಪಕ್ಷ ಯಾರು ಎಂದು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಬದಿಗಳು ಒಂದೇ ಕೀಗಳನ್ನು ಲೆಕ್ಕಿಸಬಲ್ಲವು ಮತ್ತು ಒಂದು ಪ್ರಸ್ತಾಪದ ಮೇಲೆ ಒಪ್ಪುತ್ತವೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸುತ್ತದೆ. ಯಾವ ಪ್ರಸ್ತಾಪವೂ ಇಷ್ಟವಾಗದ ಪ್ರತಿಸ್ಪಂದಕನು ಇಲ್ಲಿ ವಿನಿಮಯವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತಾನೆ, ಆದ್ದರಿಂದ ಆವೃತ್ತಿ ಅಥವಾ ಅಲ್ಗಾರಿದಮ್ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆ ಸರ್ವರ್ ಬಂದ್ ಆಗಿರುವಂತೆ ಕಾಣುತ್ತದೆ.
ಈ ಹಂತದಲ್ಲಿ ರಚಿಸಲಾದ IKE SA ಎಲ್ಲಾ ನಂತರದ ನಿರ್ವಹಣಾ ವಿನಿಮಯಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. ಅದು ಅದರ ಕೆಲಸ, ಮತ್ತು ಅದು ನಿಮ್ಮ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ರಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಕೆಲಸ.
IKE_AUTH: ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ಮೊದಲ CHILD SA ನಿರ್ಮಿಸಿ
ಎರಡನೇ ವಿನಿಮಯ ಗುರುತನ್ನು ಸಾಗಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ, ಪ್ರತಿ ಪಕ್ಷವೂ ತನ್ನ ಖಾಸಗಿ ಕೀಯಿಂದ ಸಹಿ ಮಾಡಿ, ಇನ್ನೊಂದು ಪಕ್ಷವು ಮಾನ್ಯಗೊಳಿಸಬೇಕಾದ ಸರಪಳಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ; EAP ಯೊಂದಿಗೆ, ಪ್ರತಿಸ್ಪಂದಕನು ಆಯ್ಕೆ ಮಾಡಿದ ವಿಧಾನದ ಮೂಲಕ ಪ್ರಾರಂಭಿಕನಿಗೆ ಸವಾಲು ಹಾಕುತ್ತಾನೆ. ಇಲ್ಲಿ ತಪ್ಪು ಸರ್ವರ್ ಹೆಸರು, ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ತಿರಸ್ಕೃತ ಪಾಸ್ವರ್ಡ್ ಅಂತಿಮವಾಗಿ ಹೊರಬರುತ್ತದೆ.
ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ IKE_AUTH ಮೊದಲ CHILD SA ಅನ್ನೂ ಸಂಧಾನ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೇಟಾ ರಕ್ಷಣೆ ಅದೇ ಹೋಗು-ಬಾ ಪ್ರಯಾಣದಲ್ಲಿ ಒಪ್ಪಲ್ಪಡುತ್ತದೆ. ಪ್ರಾರಂಭಿಕನು ಸಂಚಾರ ಆಯ್ಕೆಕಾರಕಗಳನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತಾನೆ, ಪ್ರತಿಸ್ಪಂದಕನು ಅವನ್ನು ಸಂಕುಚಿಸಿ ಅಥವಾ ತಿರಸ್ಕರಿಸುತ್ತಾನೆ, ಮತ್ತು ಡೇಟಾ ಮಾರ್ಗದ ಕೀಗಳು IKE SA ಯಿಂದ ಪಡೆಯಲ್ಪಡುತ್ತವೆ. ಅಂದರೆ ಒಂದೇ ವಿನಿಮಯವು ಎರಡು ಬಹಳ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು: ಗುರುತು ಅಥವಾ ನೀತಿ. ಸಾಮಾನ್ಯ ಹ್ಯಾಂಡ್ಶೇಕ್ ವೈಫಲ್ಯದ ಬದಲು ಅಧಿಸೂಚನಾ ಪೇಲೋಡ್ ಅಥವಾ ದೋಷವನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಒಂದಕ್ಕೆ ಪರಿಹಾರ ಪ್ರಮಾಣಪತ್ರ, ಇನ್ನೊಂದಕ್ಕೆ ಉಪಜಾಲ ಹೊಂದಾಣಿಕೆ ಕೊರತೆ.
ಎರಡು SA, ಎರಡು ಕೆಲಸ
| ಸಂಘ | ರಕ್ಷಿಸುತ್ತದೆ | ಜೀವಿತಾವಧಿ ನಡವಳಿಕೆ |
|---|---|---|
| IKE SA | ನಿರ್ವಹಣಾ ವಿನಿಮಯಗಳು: ಕೀ ಮರುಹೊಂದಿಕೆ, ಅಳಿಸುವಿಕೆ, ಸಂರಚನಾ ಪೇಲೋಡ್ಗಳು | ತನ್ನದೇ ವೇಳಾಪಟ್ಟಿಯಂತೆ ಮರುಕೀಲಿಸಲ್ಪಡುತ್ತದೆ; ಡೇಟಾ ಮಾರ್ಗ ಬದಲಾವಣೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು |
| CHILD SA | ಸಂಚಾರ ಆಯ್ಕೆಕಾರಕಗಳಿಗೆ ಹೊಂದುವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ | ಸ್ವತಂತ್ರವಾಗಿ ಮರುಕೀಲಿಸಲ್ಪಡುತ್ತದೆ, ಹೆಚ್ಚಾಗಿ ಹೆಚ್ಚು ಪದೇ |
ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದು ದೋಷಗಳಂತೆ ಕಾಣುವ ಎರಡು ನಡವಳಿಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸುರಂಗವು ಸ್ಥಾಪಿತ ಎಂದು ತೋರಿಸಬಹುದು, ಆದರೆ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಕೀ ಮರುಹೊಂದಿಕೆ ವಿಫಲವಾಗುತ್ತಿರಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕ ಕಳೆದುಕೊಳ್ಳದೆ CHILD SA ಬದಲಾಯಿಸಬಹುದು.
strongSwan ನಲ್ಲಿ, IKEv2 ಸಂರಚನಾ ಉಲ್ಲೇಖ ಮತ್ತು swanctl --list-sas ಎರಡೂ ಹಂತಗಳನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ip xfrm state ಜೊತೆಗೆ ip xfrm policy ಕರ್ನಲ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ. ಈ ಎರಡು ನೋಟಗಳನ್ನು ಹೋಲಿಸುವುದು ಸಂಧಾನ ಮುಗಿದಿದೆಯೇ ಅಥವಾ ಮುಗಿದಂತೆ ಕಾಣುತ್ತದೆಯೇ ಎಂದು ನೋಡುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ. ಕರ್ನಲ್ನಲ್ಲಿ ಸ್ಥಿತಿ ಇಲ್ಲದ CHILD SA ಅನ್ನು ಡೀಮನ್ ಪಟ್ಟಿ ಮಾಡಿದರೆ, ಸ್ಥಾಪನೆ ಮೌನವಾಗಿ ವಿಫಲವಾಗಿದೆ. ಡೀಮನ್ಗೆ ಗೊತ್ತಿಲ್ಲದ ಸ್ಥಿತಿಯನ್ನು ಕರ್ನಲ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಹಿಂದಿನ ಪ್ರಯತ್ನದ ಉಳಿಕೆಯನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ.
ಸುರಂಗ ಮೇಲಕ್ಕೆ ಬಂದ ನಂತರವೂ ಏನು ನಿಜವಾಗಿರಬೇಕು
ಸಂಚಾರ ಆಯ್ಕೆಕಾರಕಗಳು ಯಾವ ವಿಳಾಸಗಳು ಒಳಗೊಂಡಿವೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಒಂದು ಉಪಜಾಲವನ್ನು ಪ್ರಸ್ತಾಪಿಸಿ ಸರ್ವರ್ ಇನ್ನೊಂದನ್ನು ನಿರೀಕ್ಷಿಸಿದರೆ, CHILD SA ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ ಆದರೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ, ಮತ್ತು ದೋಷವು ಸಂಧಾನದ ಸಮಸ್ಯೆಯಲ್ಲ, ಮಾರ್ಗನಿರ್ದೇಶನ ಸಮಸ್ಯೆಯಾಗಿ ಕಾಣುತ್ತದೆ. ನಂತರ ಸ್ಥಳೀಯ ಸ್ಟಾಕ್ ಸಹಕರಿಸಬೇಕು: ಹೋಸ್ಟ್ ಮಾರ್ಗನಿರ್ದೇಶಿಸುವಲ್ಲಿ ಮುಂದೆ ಕಳುಹಿಸುವಿಕೆ ಸಕ್ರಿಯ, ಸುರಂಗದ ಕಡೆಗೆ ಮಾರ್ಗಗಳು, ಡೀಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು, ಮತ್ತು ಖಾಸಗಿ ಹೆಸರುಗಳು ಒಳಗೊಂಡಿದ್ದರೆ ಆಂತರಿಕ ಪರಿಹಾರಕ. ಇವು ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು IKE ಡೀಮನ್ ಮರುಪ್ರಾರಂಭಿಸಿ ಯಾವುದೂ ಸರಿಯಾಗುವುದಿಲ್ಲ.
ರೋಗನಿರ್ಣಯ ಮಾಡುವಾಗ ಲಾಗ್ ಕಾಣುವಂತೆ ಇರಿಸಿ: ಆರಂಭಿಕ ವಿನಿಮಯ, ನಂತರ ಗುರುತು ಪರಿಶೀಲನೆ, ನಂತರ ಅನ್ವಯವಾಗುವಲ್ಲಿ ಬಳಕೆದಾರ ದೃಢೀಕರಣ, ನಂತರ CHILD ಸ್ಥಾಪನೆ ಮತ್ತು ಕೊನೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ. ನಿಲ್ಲುವ ಹಂತವೇ ಸರಿಪಡಿಸಬೇಕಾದ ಹಂತ, ಮತ್ತು ನಂತರದ ಮಾರ್ಗನಿರ್ದೇಶನ ವೈಫಲ್ಯವು ಈಗಾಗಲೇ ದಾಟಿದ ಗುರುತು ಪರಿಶೀಲನೆಗಳನ್ನು ಸಡಿಲಿಸಲು ಎಂದಿಗೂ ಕಾರಣವಲ್ಲ.