Windows ಮತ್ತು FortiGate ನಲ್ಲಿ IKEv2: ಜನರು ಸೇರಿಸುವ ಮೂರು ಸೆಟ್ಟಿಂಗ್ಗಳು
IKE ಕೀ ವಿನಿಮಯ, CHILD SA ರಕ್ಷಣೆ ಮತ್ತು ಪೀರ್ ದೃಢೀಕರಣ ಮೂರು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳು. ಎರಡು ಸಂವಾದಗಳಲ್ಲಿ ಗುಂಪು ಸಂಖ್ಯೆಗಳು ಹೊಂದಿಕೆಯಾದರೂ ಅವು ಸೇರುವುದಿಲ್ಲ.
Windows ಕ್ಲೈಂಟ್ ಮತ್ತು FortiGate ಗೇಟ್ವೇ ನಡುವಿನ IKEv2 ಒಪ್ಪಂದವು ವಿಫಲವಾಗುತ್ತಲೇ ಇದೆ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗದ ಸಂಖ್ಯೆಯ ಹುಡುಕಾಟವು ಇನ್ನೂ ಉದ್ದವಾದ ಸಂಖ್ಯೆಗಳ ಪಟ್ಟಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಪಟ್ಟಿಯನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುವ ಮೂರು ಸಾಲುಗಳಾಗಿ ವಿಭಜಿಸಿದಾಗ ಮಾತ್ರ ಅದು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ: IKE ಅನ್ನು ರಕ್ಷಿಸುವ ಕೀ ವಿನಿಮಯ, CHILD SA ಗೆ ಅನ್ವಯಿಸುವ ರಕ್ಷಣೆ, ಮತ್ತು ಪ್ರತಿ ಬದಿಯು ಯಾರು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುವ ದೃಢೀಕರಣ. ಗುಂಪು ಸಂಖ್ಯೆಗಳು ಆ ಸಾಲುಗಳಲ್ಲಿ ಎರಡರಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಬೇರೆ ಅರ್ಥಗಳನ್ನು ಹೊಂದಿವೆ.
ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುವ ಮೂರು ಸಾಲುಗಳು
ಮೊದಲ ಸಾಲು IKE ಒಳಗಿನ ಕೀ ವಿನಿಮಯವಾಗಿದ್ದು, ಮಾತುಕತೆಯನ್ನು ರಕ್ಷಿಸುವ ಕೀಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಎರಡನೆಯದು CHILD SA ಗಾಗಿ ಪ್ರಸ್ತಾವವಾಗಿದ್ದು, ಸುರಂಗವು ಸಾಗಿಸುವ ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. ಮೂರನೆಯದು ದೃಢೀಕರಣವಾಗಿದ್ದು, ಪ್ರತಿ ಬದಿಯು ಏನನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಬದಿಯು ಅದನ್ನು ಹೇಗೆ ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ವೈಫಲ್ಯಗಳು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ. ವಿನಿಮಯದ ವೈಫಲ್ಯವು ಯಾವುದೇ ಸುರಂಗ ಇರುವ ಮೊದಲೇ ಮಾತುಕತೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. CHILD SA ವೈಫಲ್ಯವು ದೃಢೀಕರಣ ಯಶಸ್ವಿಯಾದ ನಂತರ ಸಂಭವಿಸುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಕೀ ನವೀಕರಣದಲ್ಲಿ ಮಾತ್ರ. ದೃಢೀಕರಣದ ವೈಫಲ್ಯವು ಲಾಗ್ಗಳಲ್ಲಿ ವಿನಿಮಯದ ವೈಫಲ್ಯದಂತೆ ಕಾಣಬಹುದು, ನೀವು ಮೊದಲ ದೋಷವನ್ನು ಮಾತ್ರ ಓದಿದರೆ.
ಸಾಲುಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಲೆಕ್ಕಪತ್ರವಲ್ಲ. ಯಾವ ಸೆಟ್ಟಿಂಗ್ ಬದಲಾಯಿಸಲು ಯೋಗ್ಯವೆಂದು ಅದು ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಈ ಇಡೀ ಕ್ಷೇತ್ರದ ಅತ್ಯಂತ ದುಬಾರಿ ಹೆಜ್ಜೆಯನ್ನು ತಡೆಯುತ್ತದೆ, ಅಂದರೆ ಪ್ರಸ್ತಾವದ ಅಸಂಗತಿಯನ್ನು ಸರಿಪಡಿಸಲು ಕೆಲಸ ಮಾಡುವ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು. ಒಂದು ಸಾಲಿನ ಬದಲಾವಣೆಯು ಇತರ ಎರಡನ್ನು ತನ್ನೊಂದಿಗೆ ಬದಲಾಯಿಸಲು ಒತ್ತಾಯಿಸಬಾರದು. ಆ ಸ್ವಾತಂತ್ರ್ಯವೇ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯುವ ಸಂಪೂರ್ಣ ಉದ್ದೇಶ.
Windows ನ ಎರಡು ಕ್ಷೇತ್ರಗಳು ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ
Windows ಎರಡು ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುತ್ತದೆ: DHGroup ಸ್ವತಃ IKE ವಿನಿಮಯವನ್ನು ಸಂರಚಿಸುತ್ತದೆ, ಆದರೆ PfsGroup ಸುರಂಗದೊಳಗಿನ ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸುವ IPsec ನೀತಿಯನ್ನು ಸಂರಚಿಸುತ್ತದೆ. ಅವು ಬೇರೆ ಬೇರೆ ಹಂತಗಳಿಗೆ ಸೇರಿವೆ. Windows ನ IKE ಕ್ಷೇತ್ರವನ್ನು FortiGate ನ ಹಂತ 2 ಮೌಲ್ಯದೊಂದಿಗೆ ಹೋಲಿಸುವುದು ತಪ್ಪು ಜೋಡಿಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಖ್ಯೆಗಳು ಹೊಂದಿಕೆಯಾಗಬಹುದು ಆದರೆ ಆಧಾರವಾದ ವಿನಿಮಯವು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಆಜ್ಞೆಗಳು ವಾಸ್ತವವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಭದ್ರತಾ ಸಂಘಟನೆಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಇದು ಕ್ಲೈಂಟ್ ನಿಮಗೆ ನೀಡಬಹುದಾದ ಉತ್ತರಕ್ಕೆ ಅತ್ಯಂತ ಹತ್ತಿರದ ವಿಷಯ. ಮುಖ್ಯ ಮೋಡ್ ಸಂಘಟನೆ ಇದ್ದು ವೇಗದ ಮೋಡ್ ಸಂಘಟನೆ ಇಲ್ಲದಿರುವುದು CHILD SA ಸಮಸ್ಯೆಯಾಗಿದ್ದು, ಇದು ಪ್ರಮಾಣಪತ್ರದ ಸಮಸ್ಯೆಯಲ್ಲ, ಹಂತ 2 ಅಸಂಗತಿಯ ಸಂಕೇತವಾಗಿದೆ.
ಒಂದು ಪ್ರಯತ್ನದಲ್ಲಿ ಏನು ಪ್ರಸ್ತಾಪಿಸಲಾಯಿತು ಮತ್ತು ಏನು ಆಯ್ಕೆಯಾಯಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಸ್ವೀಕಾರಾರ್ಹ ಪ್ರಸ್ತಾವವನ್ನು ಹೊಂದಿರುವ ಪ್ರಸ್ತಾಪ ಪಟ್ಟಿ ಮತ್ತು ಗೇಟ್ವೇ ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ಆಯ್ಕೆಯಾದ ಪ್ರಸ್ತಾವವು ಸಂರಚನಾ ಭಿನ್ನಾಭಿಪ್ರಾಯ, ಪರಸ್ಪರ ಕಾರ್ಯಕ್ಷಮತೆಯ ರಹಸ್ಯವಲ್ಲ.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ಗುಂಪು ನಿಮ್ಮ ಸಹಿ ಕೀಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ
ಈ ಕ್ಷೇತ್ರದ ಅತ್ಯಂತ ಪಟ್ಟುಬಿಡದ ತಪ್ಪು ಅನುಮಾನವೆಂದರೆ ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ DH ಗುಂಪನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ಪ್ರಮಾಣಪತ್ರ ಬೇಕು ಎಂಬುದು. DH ಗುಂಪು ಕೀ ವಿನಿಮಯದ ವಸ್ತುವನ್ನು ಒದಗಿಸುತ್ತದೆ; ಸಹಿ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ದೃಢೀಕರಣ ಚೌಕಟ್ಟು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು IKEv2 ನಲ್ಲಿ ಇವು ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು.
RFC 7427 ಆ ನಿರ್ಧಾರಗಳು ಹಿಂದೆ ಹೆಣೆದುಕೊಂಡಿದ್ದರಿಂದಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಮತ್ತು ಸಹಿ ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ಕೀ ವಿನಿಮಯದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಹೇಗೆ ಘೋಷಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಗೇಟ್ವೇ ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಕ್ರರೇಖೆಯ ಗುಂಪು ಮತ್ತು ಸಹಿ ಯೋಜನೆಗಳ ಆಯ್ಕೆ ಎರಡನ್ನೂ ಬೆಂಬಲಿಸಬಹುದು.
ಆದ್ದರಿಂದ ಗುಂಪು ಬದಲಾವಣೆಯ ನಂತರ ಮಾತುಕತೆ ವಿಫಲವಾದಾಗ, ಪ್ರಮಾಣಪತ್ರದ ಕೀ ಪ್ರಕಾರವನ್ನು ನೋಡುವ ಮೊದಲು ದೃಢೀಕರಣ ವಿಧಾನವನ್ನು ನೋಡಿ. ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬದಲಾಯಿಸುವುದು ನಿಧಾನ ಮತ್ತು ಅಪಾಯಕಾರಿ ಕಾರ್ಯವಾಗಿದ್ದು ಅದು ಅಪರೂಪಕ್ಕೆ ಉತ್ತರವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಮೊದಲು ಮಾಡುವುದು ಯಾವ ಬದಲಾವಣೆ ನಿಜವಾಗಿ ಸಹಾಯ ಮಾಡಿತು ಎಂಬುದನ್ನು ತಿಳಿಯುವ ನಿಮ್ಮ ಸಾಮರ್ಥ್ಯವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ ಸಂಗ್ರಹವನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ದೃಢೀಕರಣ ಸಾಲನ್ನು ಓದಿ.
ಎರಡನ್ನೂ ಒಪ್ಪಂದದ ಹಾಳೆಯ ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ತಪ್ಪು ಪ್ರಲೋಭನೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಒಂದು ಸಾಲು ಗುಂಪುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಸಹಿ ಯೋಜನೆಗಳು ಮತ್ತು ಗುರುತುಗಳನ್ನು, ಮತ್ತು ಯಾವುದೂ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಪ್ರತಿ ಖಾಸಗಿ ಕೀಯನ್ನು ಅದರ ನಿಜವಾದ ಮಾಲೀಕರ ಬಳಿ ಇರಿಸಿ
ತನ್ನದೇ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಗೇಟ್ವೇಗೆ ಅದಕ್ಕೆ ಹೊಂದುವ ಖಾಸಗಿ ಕೀ ಬೇಕು. ಸರಪಳಿಯನ್ನು ಮೌಲ್ಯೀಕರಿಸುವ ಪೀರ್ಗೆ CA ಪ್ರಮಾಣಪತ್ರ ಬೇಕು, ಮತ್ತು ವಿಶೇಷವಾಗಿ CA ಯ ಸಹಿ ಕೀ ಬೇಕಿಲ್ಲ. ಈ ಮೂರು ಅಂಶಗಳನ್ನು ಬೆರೆಸುವುದೇ ಜನರು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬೇರೆ ವರ್ಗದಲ್ಲಿ ಕಾಣಿಸಲು VPN ಸಾಧನಕ್ಕೆ CA ಯ ಖಾಸಗಿ ಕೀಯನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವ ಕಾರಣ.
FortiOS ನಲ್ಲಿ ಪಾತ್ರಗಳು ವಿಭಿನ್ನವಾಗಿವೆ: ಅದರ ಕೀಯೊಂದಿಗೆ ಸ್ಥಳೀಯ ಪ್ರಮಾಣಪತ್ರ, ಪೀರ್ ಅನ್ನು ಗುರುತಿಸಲು ಬಳಸುವ ದೂರದ ಪ್ರಮಾಣಪತ್ರ, ಮತ್ತು ಆ CA ಸಹಿ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರಗಳಲ್ಲಿ ವಿಶ್ವಾಸವನ್ನು ಸ್ಥಾಪಿಸುವ ದೂರದ CA ನಮೂದು. ಖಾಸಗಿ ಕೀ ಇಲ್ಲದ ದೂರದ CA ನಮೂದು ಅಪೂರ್ಣವಲ್ಲ; ಅದು ತನ್ನ ಉದ್ದೇಶಕ್ಕೆ ಸರಿಯಾಗಿದೆ.
ಆಮದು ಮಾಡಿದ CA ಸಹಿ ಕೀಗಳು ಆ ಸಾಧನವನ್ನು ಓದಬಲ್ಲ ಯಾರಿಗಾದರೂ ಅಧಿಕಾರವನ್ನು ವಿಸ್ತರಿಸುತ್ತವೆ. ಅವು ಸಾಮಾನ್ಯ ಪೀರ್ ಮೌಲ್ಯೀಕರಣವನ್ನೂ ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಮೌಲ್ಯೀಕರಣಕ್ಕೆ ಸಾರ್ವಜನಿಕ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ವಿಶ್ವಾಸದ ನಿರ್ಧಾರ ಬೇಕು, ಹೊಸ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಸಾಮರ್ಥ್ಯವಲ್ಲ.
CA ಯ ಸಹಿ ಕೀಯನ್ನು ನೀಡುಗರ ಸ್ವಂತ ಪ್ರಕ್ರಿಯೆಯ ಬಳಿ ಇರಿಸಿ, ಮತ್ತು ಯಾವ ಸಾಧನವು ಯಾವ ಕೀಯನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಕೈಗೊಳ್ಳುವ ತಪಾಸಣೆ ಯಾರು ಯಾರನ್ನು ಅನುಕರಿಸಬಹುದಿತ್ತು ಎಂದು ಕೇಳಿದಾಗ ಮಾಲೀಕರ ಸಣ್ಣ ಕೋಷ್ಟಕವು ಅಲ್ಗಾರಿದಮ್ಗಳ ಉದ್ದವಾದ ಕೋಷ್ಟಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿದೆ. ಯಾರೂ ತಾವು ಕೇವಲ ದಾಸ್ತಾನಿಗೆ ಎಂದು ತಿಳಿದಿರುವ ಕೀಯನ್ನು ಆಮದು ಮಾಡುವುದಿಲ್ಲ. ಘಟನೆಯ ನಂತರವಲ್ಲ, ಮೊದಲು ದಾಸ್ತಾನನ್ನು ಬರೆಯಿರಿ.