IKEv1 ನ ಹೈಬ್ರಿಡ್ ದೃಢೀಕರಣ IKEv2 ನ ಬಳಕೆದಾರ ದೃಢೀಕರಣಕ್ಕೆ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ
ಹೈಬ್ರಿಡ್ ಮೋಡ್ ಗೇಟ್ವೇಯ ಸಾಕ್ಷ್ಯವನ್ನು ಬಳಕೆದಾರರ ಸಾಕ್ಷ್ಯದಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತಿತ್ತು. IKEv2 ಗೆ ಬದಲಾದಾಗ ಆ ಪ್ರತ್ಯೇಕತೆ ಉಳಿಯುತ್ತದೆ, ಆದರೆ ವಿನಿಮಯ, EAP ವಿಧಾನ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರದ ಪರಿಶೀಲನೆಗಳು ಬದಲಾಗುತ್ತವೆ.
ಮೊದಲು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ, ನಂತರ ಬಳಕೆದಾರ ಹೆಸರು ಕೇಳುವ ಪ್ರತಿ ಹಳೆಯ VPN ಪ್ರೊಫೈಲ್ ಒಂದೇ ವಿನಿಮಯದಲ್ಲಿ ದೃಢೀಕರಣದ ಎರಡು ಘಟನೆಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಈ ಆಕಾರ ಅದನ್ನು ತಂದ ಪ್ರೋಟೋಕಾಲ್ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ. IKEv1 ನ ಹೈಬ್ರಿಡ್ ಮೋಡ್ ಸರಿಯಾಗಿ ಇದಕ್ಕಾಗಿಯೇ ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿತು: ಗೇಟ್ವೇ ತನ್ನನ್ನು ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಿಂದ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಬಳಕೆದಾರ ಮುಂದೆ XAuth ಮೂಲಕ ತನ್ನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತಾನೆ. IKEv2 ಅದೇ ಎರಡು-ಹಂತದ ಕಲ್ಪನೆಯನ್ನು ಬೇರೆ ಯಂತ್ರರಚನೆಯಿಂದ ವ್ಯಕ್ತಪಡಿಸುತ್ತದೆ, ಈ ವ್ಯತ್ಯಾಸಗಳಲ್ಲಿಯೇ ಸ್ಥಳಾಂತರಗಳು ವಿಫಲವಾಗುತ್ತವೆ. ಯಾವ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯೂ ಒಂದನ್ನು ಇನ್ನೊಂದಾಗಿ ಬದಲಿಸುವುದಿಲ್ಲ, ಹಳೆಯ ಆಯ್ಕೆಗಳ ಹೆಸರುಗಳನ್ನು ಹೊಸ ಪ್ರೊಫೈಲ್ಗೆ ನಕಲಿಸುವುದು ಮಾತುಕತೆ ನಡೆಸಿ ನಂತರ ಏನನ್ನೂ ದೃಢೀಕರಿಸದ ಕ್ಲೈಂಟ್ ನೀಡುತ್ತದೆ.
ಹೈಬ್ರಿಡ್ ಮೋಡ್ IKEv1 ಒಳಗೆ ಏನು ಮಾಡಿತು
ಹೈಬ್ರಿಡ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಉತ್ತರಿಸುವ ಪಕ್ಷ ಮೊದಲ ಹಂತದ ವಿನಿಮಯವನ್ನು ತನ್ನ ಪ್ರಮಾಣಪತ್ರದಿಂದ ಸಹಿ ಮಾಡುತ್ತದೆ, ಪ್ರಾರಂಭಿಸುವವನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಯಾವ ಪ್ರಮಾಣಪತ್ರವನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಗುರುತಿನ ಸಾಕ್ಷ್ಯ ಅಸಮ್ಮಿತವಾಗಿದೆ, ಇದೇ ಗೇಟ್ವೇಗೆ ತನ್ನ ಪ್ರಸ್ತುತ PKI ಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಲು, ಬಳಕೆದಾರರಿಗೆ ತಮ್ಮ ಡೈರೆಕ್ಟರಿ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡಿತು. ಮೊದಲ ಹಂತ ಮುಗಿದ ನಂತರ XAuth ವಿನಂತಿ ಮತ್ತು ಉತ್ತರವಾಗಿ ನಡೆಯುತ್ತದೆ, ಅವು ಈಗ ಗೂಢಲಿಪೀಕರಿಸಿದ ISAKMP ಚಾನಲ್ ಒಳಗೆ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತವೆ.
ನಂಬಿಕೆ ಎಲ್ಲಿ ಬೀಳುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ. ಪ್ರಮಾಣಪತ್ರ ಕ್ಲೈಂಟ್ ಯಾವ ಗೇಟ್ವೇ ತಲುಪಿತು ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ; XAuth ಯಾವ ಬಳಕೆದಾರ ಪ್ರವೇಶ ಬಯಸುತ್ತಾರೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಒಂದು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಿಯಲ್ಲ, ಯಾವ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನೂ ಸ್ವೀಕರಿಸುವಂತೆ ಇರಿಸಿದ ಕ್ಲೈಂಟ್ ಮೊದಲ ಉತ್ತರವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡಿದೆ. ಹೈಬ್ರಿಡ್ ಎಂಬ ಲೇಬಲ್ ಮೊದಲೇ ಹಂಚಿದ ಕೀಲಿಯೊಂದಿಗಿನ ಆಕ್ರಮಣ ಮೋಡ್ ಮತ್ತು XAuth ಗೂ ಬಳಸಲ್ಪಡುತ್ತದೆ, ಅದು ಅದೇ ಬಳಕೆದಾರ ಅನುಭವವಿರುವ ಬೇರೆ ಏರ್ಪಾಡು, ಆದ್ದರಿಂದ ಹೆಸರನ್ನಲ್ಲ, ಪ್ರೊಫೈಲ್ ಓದಿ. ಎರಡೂ ರೂಪಗಳು ಎಂದಿಗೂ ಮಾನದಂಡವಾಗದ ಕರಡುಗಳಿಂದ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದಲೇ ಇಬ್ಬರು ತಯಾರಕರು ಹೈಬ್ರಿಡ್ ಮೋಡ್ ಜಾರಿಗೊಳಿಸಿ ಯಾರೊಂದಿಗೂ ಪರಸ್ಪರ ಕ್ರಿಯೆ ಇಲ್ಲದಿರಬಹುದು.
IKEv2 ಅದೇ ಎರಡು ಸಾಕ್ಷ್ಯಗಳನ್ನು ಹೇಗೆ ತಲುಪುತ್ತದೆ
IKEv2 ಕೆಲಸವನ್ನು IKE_SA_INIT ಮತ್ತು IKE_AUTH ನಡುವೆ ವಿಭಜಿಸುತ್ತದೆ. ಮೊದಲ ವಿನಿಮಯ ಯಾವ ಗುರುತೂ ಇಲ್ಲದೆ ಪ್ರಸ್ತಾವಗಳು ಮತ್ತು ಕೀಲಿಗಳ ಮೇಲೆ ಒಪ್ಪುತ್ತದೆ; ಎರಡನೆಯದು IDi, IDr ಮತ್ತು AUTH ಹೊರೆಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. EAP ಅಡಿಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸುವವನ ಮೊದಲ AUTH ಹೊರೆ ಖಾಲಿಯಾಗಿ ಹೋಗುತ್ತದೆ, ಉತ್ತರಿಸುವ ಪಕ್ಷ ಮೊದಲು ತನ್ನ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಸಹಿಯಿಂದ ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತದೆ, ನಂತರ EAP ಸಂಭಾಷಣೆ IKE_AUTH ಸಂದೇಶಗಳ ಒಳಗೆ ನಡೆಯುತ್ತದೆ.
ಇದನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವ ಯಂತ್ರರಚನೆ ಕೀಲಿ ಸಾಮಗ್ರಿ. ಯಶಸ್ವಿ EAP ವಿಧಾನ ಸೆಷನ್ ಕೀಲಿಯನ್ನು ರಫ್ತು ಮಾಡುತ್ತದೆ, ಪ್ರಾರಂಭಿಸುವವನ ಅಂತಿಮ AUTH ಹೊರೆ ಅದರಿಂದ ಲೆಕ್ಕಹಾಕಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಬಳಕೆದಾರರ ಸಾಕ್ಷ್ಯ ಮತ್ತು ಸುರಂಗದ ಕೀಲಿಗಳು ಒಂದಕ್ಕೊಂದು ಬಂಧಿಸಲ್ಪಡುತ್ತವೆ. XAuth ಗೆ ಅಂತಹ ಸಮಾನ ಅರ್ಥವಿಲ್ಲ: ಅದರ ಗುಣಲಕ್ಷಣಗಳು ಮೊದಲ ಹಂತದ ನಂತರ ಬರುತ್ತವೆ, ಕೀಲಿಗಳಿಗೆ ಏನನ್ನೂ ಸೇರಿಸುವುದಿಲ್ಲ. ಈ ಕಂದಕವನ್ನು ತುಂಬಲು IKEv2 ಚೌಕಟ್ಟು ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟಿತು, ಆದ್ದರಿಂದಲೇ ಕೆಲಸ ಮಾಡುವ IKEv2 ಲಾಗಿನ್ ಏನನ್ನಾದರೂ ಕೇಳುವ ಮೊದಲು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.
ಈ ಕ್ರಮ ಉಪಯುಕ್ತ ನಿರ್ಣಯವೂ ಹೌದು. ಕ್ಲೈಂಟ್ ನಿಮಗೆ ಪ್ರಮಾಣಪತ್ರ ತೋರಿಸುವ ಮೊದಲೇ ರುಜುವಾತುಗಳ ಬಗ್ಗೆ ದೂರು ನೀಡಿದರೆ, ಅವನು IKEv2 EAP ವಿನಿಮಯವನ್ನೇ ಮಾಡುತ್ತಿಲ್ಲ.
ಮೂರು ಗುರುತುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ
ಮೂರು ಗುರುತುಗಳು ಒಂದೇ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕುಸಿದಾಗ ಸ್ಥಳಾಂತರ ತಪ್ಪಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಪರಿಶೀಲಿಸುವ ಗೇಟ್ವೇ ಗುರುತು ಇದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಮಾಣಪತ್ರದ subject ಅಥವಾ SAN ನಲ್ಲಿ DNS ಹೆಸರು. EAP ನಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸುವ ಬಳಕೆದಾರ ಗುರುತು ಇದೆ, ಡೊಮೇನ್ ಲಾಗಿನ್, ವಿಳಾಸ ಅಥವಾ ಸ್ಪಷ್ಟ EAP ಗುರುತು ಸ್ಟ್ರಿಂಗ್ ಆಗಿರಬಹುದು. ಮತ್ತು ಆ ಬಳಕೆದಾರನನ್ನು ನೆಟ್ವರ್ಕ್ಗಳಿಗೆ, ಮಾರ್ಗಗಳಿಗೆ ನಕ್ಷೆ ಮಾಡುವ ಅನುಮತಿ ಮೂಲ ಇದೆ.
strongSwan ನ swanctl ವಾಕ್ಯರಚನೆ ವಿಭಜನೆಯನ್ನು ಕಾಣುವಂತೆ ಮಾಡುತ್ತದೆ: ಸಂಪರ್ಕ ಗೇಟ್ವೇಗೆ remote { auth = pubkey } ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ local { auth = eap-mschapv2 } ಹೊಂದಿಸುತ್ತದೆ, EAP ಗುರುತು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಾಗಿಸಲ್ಪಡುತ್ತದೆ.
ಹೊಸ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಬಳಕೆದಾರ ಗುರುತು ಹಳೆಯ XAuth ಗುಣಲಕ್ಷಣಗಳಿಗಿಂತ ಭಿನ್ನವಾದರೆ, ಉದಾಹರಣೆಗೆ ಸಣ್ಣ ಹೆಸರಿನ ಬದಲು UPN, ದೃಢೀಕರಣ ಸರ್ವರ್ ಅಪರಿಚಿತ ಬಳಕೆದಾರನನ್ನು ಕಾಣುತ್ತದೆ, ವೈಫಲ್ಯ ತಪ್ಪು ಪಾಸ್ವರ್ಡ್ನಂತೆ ಕಾಣುತ್ತದೆ. ರುಜುವಾತುಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಗುರುತು ಸ್ಟ್ರಿಂಗ್ ಪರಿಶೀಲಿಸಿ.
ಆಯ್ಕೆಗಳನ್ನು ನಕ್ಷೆ ಮಾಡಿ, ನಂತರ ಬಲೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ
ನಕ್ಷೆ ಚಿಕ್ಕದು, ಪ್ರತಿ ಸಾಲಿನಲ್ಲಿ ದೃಢೀಕರಣದ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಕಾಣುವ ಒಂದು ಬಲೆ ಇರುತ್ತದೆ.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ಆ ಸಾಲುಗಳಲ್ಲಿ ಯಾವುದೂ ಕೇವಲ ಹೆಸರು ಬದಲಾವಣೆಯಲ್ಲ. ಸಂರಚನಾ ಹೊರೆ ವಿಳಾಸಗಳನ್ನು ಮತ್ತು ಪರಿಹಾರಕಗಳನ್ನು ಟೈಪ್ ಮಾಡಿದ ಗುಣಲಕ್ಷಣ ಪಟ್ಟಿಯ ಮೂಲಕ ತಲುಪಿಸುತ್ತದೆ, XAuth ನ ಗುಣಲಕ್ಷಣ ಕ್ಷೇತ್ರ ಅದರ ಸ್ವಂತ ಆವಿಷ್ಕಾರ; ಅವನ್ನು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದವು ಎಂದು ಪರಿಗಣಿಸುವುದೇ ಪ್ರೊಫೈಲ್ ಗೇಟ್ವೇ ಎಂದಿಗೂ ಕಳುಹಿಸದ ಸೆಟ್ಟಿಂಗ್ ಕೇಳುವ ಮಾರ್ಗ.
ಸಂಚಾರ ಆಯ್ಕೆಗಾರರು ತಮ್ಮದೇ ಎಚ್ಚರಿಕೆಗೆ ಅರ್ಹರು. IKEv1 ಕುತೂಹಲಕರ ಸಂಚಾರವನ್ನು quick mode ವಿನಿಮಯಕ್ಕೆ ಬದ್ಧವಾದ ಪ್ರಾಕ್ಸಿ ಐಡಿಗಳಿಂದ ವ್ಯಕ್ತಪಡಿಸುತ್ತಿತ್ತು, IKEv2 IKE_AUTH ಸಮಯದಲ್ಲಿ ಆಯ್ಕೆಗಾರರ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ಉತ್ತರಿಸುವ ಪಕ್ಷ ಅವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು. ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದಾಗ child SA ಇಲ್ಲದ ಸ್ಥಾಪಿತ IKE SA ಉಂಟಾಗುತ್ತದೆ, ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ಅದನ್ನು ಸಂತೋಷದಿಂದ ಸಂಪರ್ಕಿತವೆಂದು ತೋರಿಸುತ್ತವೆ.
ಹಳೆಯ ಸಂಪರ್ಕವನ್ನು ಗಡಿಯಾಗಿ ಪರಿಗಣಿಸಿ
RFC 9395 IKEv1 ಅನ್ನು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ್ದು ಎಂದು ಘೋಷಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ಹೈಬ್ರಿಡ್ ಸಂಪರ್ಕ ದಿನಾಂಕವಿರುವ ಹೊಂದಾಣಿಕೆ ಗಡಿ, ತಳಹದಿ ಅಲ್ಲ. ಬದಲಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಎರಡೂ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ನಡೆಸಿ, ಏಕೆಂದರೆ ಮುಖ್ಯ ಪರೀಕ್ಷೆ ಹೊಸ ಪ್ರೊಫೈಲ್ ಏಳುತ್ತದೆಯೇ ಎಂಬುದಲ್ಲ, ಅದೇ ಬಳಕೆದಾರ ಅದೇ ಸಾಧನದಲ್ಲಿ ಅದೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಲುಪುತ್ತಾರೆಯೇ ಎಂಬುದು.
ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಇಡಿ. ಕ್ಲೈಂಟ್ ತನ್ನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತೋರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಕೂಡಲೇ, ಕೈಕುಲುಕುವಿಕೆ ಮುಗಿಯುವವರೆಗೆ ಸರ್ವರ್ ಪರಿಶೀಲನೆಯನ್ನು ಸಡಿಲಿಸುವ ಪ್ರಲೋಭನೆ ಬರುತ್ತದೆ, ಅದು ಉಳಿದಿರುವ ಏಕೈಕ ಸಾಕ್ಷ್ಯವನ್ನು ಹಸಿರು ಚಿಹ್ನೆಯಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ.
ಹಳೆಯ ಪ್ರೊಫೈಲ್ ನಿವೃತ್ತಿಗೊಳಿಸುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಬರೆಯಿರಿ: EAP ವಿಧಾನ, ಗುರುತು ಸ್ಟ್ರಿಂಗ್, ಅನುಮತಿ ಮೂಲ ಮತ್ತು ಬೆಂಬಲ ಮುಗಿಯುವ ದಿನಾಂಕ.