IPsec ಪ್ರಸ್ತಾವನೆಯಲ್ಲಿ ಏನು ಇರುತ್ತದೆ? IKE ಮತ್ತು ESP ಕ್ಷೇತ್ರಗಳು
ಪ್ರಸ್ತಾವನೆ ಒಂದು ಸಂಪೂರ್ಣ ಕೊಡುಗೆ, ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಚೀಲವಲ್ಲ. ಯಾವ ಕ್ಷೇತ್ರಗಳು IKE ಗೆ ಮತ್ತು ಯಾವುವು ESP ಗೆ ಸೇರಿವೆ, ಮತ್ತು ಒಂದು ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆ ಏಕೆ ಇಡೀ ಗುಂಪನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ.
IKE ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಎರಡೂ ಪೀರ್‌ಗಳು AES ಅನ್ನು ಘೋಷಿಸುತ್ತವೆ, ಆದರೂ ಸುರಂಗ NO_PROPOSAL_CHOSEN ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಲಾಗ್ ಪ್ರಸ್ತಾವನೆಯ ಹೆಸರನ್ನು ಹೇಳುತ್ತದೆ ಆದರೆ ಹೊಂದಿಕೆಯಾಗದ ಕ್ಷೇತ್ರವನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಪ್ರಸ್ತಾವನೆ ಒಂದು ಸಂಪೂರ್ಣ ಕೊಡುಗೆ, ಮತ್ತು ಒಂದು ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದ ಕ್ಷೇತ್ರ ಆ ಸಾಲಿನಷ್ಟೇ ಅಲ್ಲ, ಇಡೀ ಸಂಯೋಜನೆಯನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಇದನ್ನು ಸ್ವತಂತ್ರ ಅಲ್ಗಾರಿದಮ್ ಆಯ್ಕೆಗಳ ಚೀಲವಾಗಿ ಓದುವುದೇ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆ ಕಣ್ಮರೆಯಾಗಿ ಉಳಿಯುವ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಪ್ರತ್ಯೇಕ ಪ್ರಸ್ತಾವನೆ ಪಟ್ಟಿಗಳಿರುವ ಎರಡು ಮಾತುಕತೆಗಳು
IKEv2 ಎರಡು ಭದ್ರತಾ ಸಂಘಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಮೊದಲನೆಯದು IKE SA, ಅದು ನಿಯಂತ್ರಣ ವಿನಿಮಯವನ್ನೇ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು CHILD SA, ಅದು ನಿಮ್ಮ ಸಂಚಾರವನ್ನು ESP ಮೂಲಕ ಸಾಗಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಪ್ರಸ್ತಾವನೆ ಪಟ್ಟಿ ಇದೆ, ಮತ್ತು ಪೀರ್ ಒಂದನ್ನು ಸ್ವೀಕರಿಸಿ ಇನ್ನೊಂದನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು.
ಈ ವಿಭಜನೆ ಸಾಮಾನ್ಯ ಗೊಂದಲವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಕಾರ್ಯನಿರ್ವಹಿಸುವ IKE SA ನಿಯಂತ್ರಣ ಚಾನಲ್‌ನ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಹೊಂದಿಕೆಯಾದವು ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. CHILD ಪ್ರಸ್ತಾವನೆ ವಿಫಲವಾದರೆ, ಮೊದಲ ಹಂತ ಪೂರ್ಣಗೊಂಡರೂ ಮತ್ತು ಲಾಗ್‌ಗಳು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಆರೋಗ್ಯಕರವಾಗಿ ಕಂಡರೂ, ಸುರಂಗ ಒಂದೂ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವುದಿಲ್ಲ.
ಪ್ರತಿ ಪಟ್ಟಿಯೊಳಗಿನ ಕ್ರಮವೂ ಮುಖ್ಯ. ಪ್ರತಿಸ್ಪಂದಕ ಪ್ರಾರಂಭಕನ ಕ್ರಮಬದ್ಧ ಕೊಡುಗೆಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಶಾಲವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ನಮೂದನ್ನು ಸಂಕುಚಿತದ ಮೇಲೆ ಸರಿಸಿದರೆ, ಯಾವ ಸೂಟ್ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ ಎಂಬುದು ಬದಲಾಗುತ್ತದೆ, ಆದರೆ ಒಂದೂ ಅಲ್ಗಾರಿದಮ್ ಹೆಸರು ಬದಲಾಗುವುದಿಲ್ಲ. ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ನಂಬುವ ಬದಲು ಆ ಕ್ರಮವನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ಪಿನ್ ಮಾಡಿ. ಸ್ಥಿರ ಕ್ರಮವು ಸೈಟ್‌ಗಳ ನಡುವಿನ ಲಾಗ್ ಹೋಲಿಕೆಯನ್ನೂ ಅರ್ಥಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ.
ಯಾವ ಕ್ಷೇತ್ರಗಳು ಯಾವ ಪ್ರಸ್ತಾವನೆಗೆ ಸೇರಿವೆ
ಕ್ಷೇತ್ರಗಳ ಗುಂಪು ಚಿಕ್ಕದು, ಆದರೆ ಎರಡು ಮಾತುಕತೆಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿ ಇಲ್ಲ. ಒಂದು ಕಾಲಮ್‌ನ ಕ್ಷೇತ್ರ ಇನ್ನೊಂದರಲ್ಲಿ ಇಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ ಕೋಷ್ಟಕವನ್ನು ಸಾಲಿನಂತೆ ಓದಿ. ವಾಕ್ಯರಚನೆ ಅನುಷ್ಠಾನದಿಂದ ಬದಲಾಗುತ್ತದೆ; strongSwan ನ ಪ್ರಸ್ತಾವನೆ ದಸ್ತಾವೇಜು ಒಂದು ನಿರ್ದಿಷ್ಟ ಉಲ್ಲೇಖವಾಗಿದೆ.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕ್ಷೇತ್ರ ಸೈಫರ್ ಅನ್ನು ಮತ್ತು ಬಹುತೇಕ ವಾಕ್ಯರಚನೆಗಳಲ್ಲಿ ಅದರ ಕೀ ಉದ್ದವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಸಮಗ್ರತೆ ಕ್ಷೇತ್ರ ಸೈಫರ್‌ಪಠ್ಯವನ್ನು ದೃಢೀಕರಿಸಲು ಬಳಸುವ ಹ್ಯಾಶ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು PRF IKE SA ಗಾಗಿ ಕೀ ಸಾಮಗ್ರಿಯನ್ನು ಪಡೆಯುವ ಕಾರ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ. DH ಗುಂಪು ಹೊಸ ಹಂಚಿದ ರಹಸ್ಯ ಸಾಮಗ್ರಿಯನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಆದರೆ ಬೇರೆ ಉದ್ದೇಶಗಳಿಗಾಗಿ.
ವಿಸ್ತೃತ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಡೇಟಾ ಮಾರ್ಗಕ್ಕೆ ಮಾತ್ರ ಸೇರಿವೆ. ಅವು ಅನುಕ್ರಮ ಸ್ಥಳವನ್ನು ವಿಸ್ತರಿಸುತ್ತವೆ ಮತ್ತು CHILD ಪ್ರಸ್ತಾವನೆಯ ಭಾಗವಾಗಿ ಮಾತುಕತೆ ನಡೆಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿನ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆ CHILD ಕೊಡುಗೆಯನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, IKE SA ಮಾತ್ರ ಮುಟ್ಟದೆ ಉಳಿಯುತ್ತದೆ.
ಒಂದು ಸಂಪೂರ್ಣ ಕೊಡುಗೆ ಹೇಗೆ ಆಯ್ಕೆಯಾಗುತ್ತದೆ
ಪ್ರತಿ ಪ್ರಸ್ತಾವನೆ ಒಂದು ಗುಂಪು, ಮತ್ತು ಪ್ರತಿಸ್ಪಂದಕ ಪ್ರತಿ ಕಡ್ಡಾಯ ಕ್ಷೇತ್ರ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರುವ ಗುಂಪನ್ನು ಹುಡುಕುತ್ತದೆ. ಎರಡೂ ಪಟ್ಟಿಗಳಲ್ಲಿ AES ಮತ್ತು SHA-256 ಇರಬಹುದು ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ನಮೂದು ಇಲ್ಲದಿರಬಹುದು, ಏಕೆಂದರೆ ಕೀ ಉದ್ದ, PRF ಅಥವಾ DH ಗುಂಪು ಭಿನ್ನವಾಗಿದೆ. ಹೋಲಿಕೆ ಪ್ರತಿ ಅಲ್ಗಾರಿದಮ್‌ಗಲ್ಲದೆ ಪ್ರತಿ ಪ್ರಸ್ತಾವನೆಗೆ ನಡೆಯುತ್ತದೆ.
ಏನೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಪ್ರತಿಸ್ಪಂದಕ ವಿಫಲವಾದ SA ಪ್ರಕಾರದೊಂದಿಗೆ NO_PROPOSAL_CHOSEN ಕಳುಹಿಸುತ್ತದೆ. ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಸೂಚನೆ ಯಾವ ಪ್ರಸ್ತಾವನೆ ಪಟ್ಟಿಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ಓದಿ; IKE ಪ್ರಸ್ತಾವನೆ ತಿರಸ್ಕೃತವಾದಾಗ ESP ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬದಲಿಸುವುದು ಡೀಬಗ್ ಚಕ್ರವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.
ಪ್ರೊಫೈಲ್ ಟ್ಯೂನ್ ಮಾಡುವಾಗ ಆಯ್ಕೆ ವರ್ತನೆಯನ್ನು ತಿಳಿಯುವುದು ಉಪಯುಕ್ತ. ಕೆಲವು ಅನುಷ್ಠಾನಗಳು ಪ್ರಾರಂಭಕನ ಕ್ರಮವನ್ನು ಇಷ್ಟಪಡುತ್ತವೆ, ಇತರವು ಸ್ಥಳೀಯ ನೀತಿಯ ಪ್ರಕಾರ ಮರುಕ್ರಮಗೊಳಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಎರಡು ಮಾರಾಟಗಾರರ ನಡುವೆ ಕೆಲಸ ಮಾಡುವ ಸೂಟ್ ಕಣ್ಮರೆಯಾಗಬಹುದು ಸಂಪರ್ಕವನ್ನು ಯಾವ ಬದಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿರುಗಿಸಿದಾಗ.
AEAD ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸುವ ಬದಲು ತೆಗೆದುಹಾಕುತ್ತದೆ
AES-GCM ಮತ್ತು ChaCha20-Poly1305 ಒಂದೇ ಕ್ರಿಯೆಯಲ್ಲಿ ದೃಢೀಕರಿಸಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ESP ಗಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದಾಗ, ಸಮಗ್ರತೆ ಅಲ್ಗಾರಿದಮ್ ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾತುಕತೆಗೆ ಬರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ AEAD ರಚನೆ ಅದನ್ನು ಈಗಾಗಲೇ ಒಳಗೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ AES-GCM ಅನ್ನು SHA-256 ನೊಂದಿಗೆ ಜೋಡಿಸುವ ಪ್ರಸ್ತಾವನೆ ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ ಅನಗತ್ಯ ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ತಿರಸ್ಕೃತ.
PRF IKE ಬದಿಯಲ್ಲಿ ಇನ್ನೂ ಪ್ರತ್ಯೇಕ. ಅದು ಪೇಲೋಡ್‌ಗಳನ್ನು ರಕ್ಷಿಸುವ ಬದಲು ನಿಯಂತ್ರಣ ಚಾನಲ್‌ಗೆ ಕೀಗಳನ್ನು ಪಡೆಯುವುದರಿಂದ, IKE ಪ್ರಸ್ತಾವನೆ AEAD ಸೈಫರ್ ಅನ್ನು PRF ಮತ್ತು DH ಗುಂಪಿನೊಂದಿಗೆ ಕಾನೂನುಬದ್ಧವಾಗಿ ಸಂಯೋಜಿಸಬಹುದು, ಆದರೆ ಅನುಗುಣವಾದ ESP ಪ್ರಸ್ತಾವನೆ AEAD ಸೈಫರ್ ಮತ್ತು ಐಚ್ಛಿಕ PFS ಗುಂಪನ್ನು ಮಾತ್ರ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
ಕೀ ಉದ್ದ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಟೋಕನ್‌ನ ಭಾಗ, ಆದ್ದರಿಂದ AES-128-GCM ಮತ್ತು AES-256-GCM ಬೇರೆ ಬೇರೆ ಕೊಡುಗೆಗಳು. 256-bit ಕೀಗಳನ್ನು ಊಹಿಸಿದ ಮಾರ್ಗದರ್ಶಿಯಿಂದ ನಕಲಿಸಿದ ಪ್ರೊಫೈಲ್ 128-bit ಗಾಗಿ ಸಂರಚಿಸಿದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಎರಡೂ ಸಾಲುಗಳು AES-GCM ಎಂದು ಹೇಳಿದರೂ. ಎರಡು ಪೀರ್‌ಗಳು ಸೈಫರ್ ಕುಟುಂಬದಲ್ಲಿ ಒಪ್ಪಿದರೂ ಡ್ಯಾಶ್ ನಂತರದ ಸಂಖ್ಯೆಯ ಕಾರಣ ಒಂದನ್ನೊಂದು ತಿರಸ್ಕರಿಸಬಹುದು.
ಸಂರಚನೆಯನ್ನಲ್ಲ, ಸ್ಥಾಪಿತ SA ಅನ್ನು ಓದಿ
ಸಂರಚಿಸಿದ ಪ್ರಸ್ತಾವನೆ ಪಟ್ಟಿ ಕೊಡುಗೆ; ಸ್ಥಾಪಿತ SA ಫಲಿತಾಂಶ. strongSwan ಮತ್ತು Linux ಕರ್ನೆಲ್‌ನಲ್ಲಿ ಎರಡೂ ನೋಟಗಳು ಲಭ್ಯವಿವೆ:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ಪ್ರತಿ SA ಗೆ ಮಾತುಕತೆಯಾದ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, CHILD AEAD ಬಳಸುತ್ತದೆಯೇ ಎಂಬುದೂ ಸೇರಿದಂತೆ. ip xfrm state ಕರ್ನೆಲ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಕೀ ನವೀಕರಣವು ನೀವು ದಾಖಲಿಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ ಸೂಟ್‌ಗೆ ಹಿಂತಿರುಗಲಿಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸುವ ಸ್ಥಳ ಅಲ್ಲಿಯೇ.
ಸರಿಪಡಿಸಿದ ನಂತರ ಆ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ ಉಳಿಸಿ. ಕ್ಲೈಂಟ್ ನವೀಕರಣ ಅದರ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಬದಲಿಸಿದಾಗ, ದಾಖಲಾದ ಸೂಟ್ ಹೋಲಿಕೆಗೆ ಮೂಲರೇಖೆಯನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಹೋಲಿಕೆ ತನಿಖೆಯನ್ನು ಮೊದಲಿನಿಂದ ಪ್ರಾರಂಭಿಸುವ ಬದಲು ಸರಿದ ಕ್ಷೇತ್ರವನ್ನು ತೋರಿಸುತ್ತದೆ.