FortiGate Azure ಮರುಕೀ: peer SA ಪ್ರಸ್ತಾವನೆ ಸ್ಥಳೀಯ ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿಲ್ಲ
ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ IKEv2 ಸುರಂಗವೂ ಬದಲಿ CHILD SA ಅನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು. ನವೀಕರಣವು ನಿಜವಾಗಿ ಮಾತುಕತೆ ನಡೆಸುವ ಪ್ರಸ್ತಾವನೆಯನ್ನು ಹೋಲಿಸಿ, ಮೊದಲ ping ಬಳಸಿದ್ದನ್ನು ಅಲ್ಲ.
ಸುರಂಗ ಮೇಲೆದ್ದಿತು, ಸಂಚಾರ ಹರಿಯಿತು, ಮತ್ತು ನಂತರ ಲಾಗ್ ಹೇಳುತ್ತದೆ peer SA proposal not match local policy. ಹೆಚ್ಚಿನ ಜನರು ಆ ಸಾಲನ್ನು ಎರಡೂ ಸಂರಚನೆಗಳು ಎಂದೂ ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ ಎಂಬ ಸಾಕ್ಷಿಯಾಗಿ ಓದುತ್ತಾರೆ. ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಹೆಚ್ಚು ಸಂಕುಚಿತ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ: ಅವು ಮೊದಲ CHILD SA ಗೆ ಹೊಂದಿಕೆಯಾದವು ಮತ್ತು ಮೊದಲ ನವೀಕರಣದಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು, ಏಕೆಂದರೆ ಮೊದಲ ಸಂಯೋಜನೆಗೆ ನಂತರದವು ಮಾಡುವ ವಿನಿಮಯ ಎಂದೂ ಬೇಕಾಗಲಿಲ್ಲ. ಆ ವ್ಯತ್ಯಾಸವೇ ನೀವು ಎಲ್ಲಿ ನೋಡಬೇಕೆಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮೊದಲ CHILD SA ಬಳುವಳಿ ಪಡೆಯುತ್ತದೆ, ನಂತರದವು ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆ
IKEv2 ನಲ್ಲಿ ಆರಂಭಿಕ CHILD SA IKE_AUTH ಸಮಯದಲ್ಲಿ ರಚನೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಅದರ ಕೀಗಳು IKE SA ನ ಕೀ ವಸ್ತುವಿನಿಂದ ಪಡೆಯಲ್ಪಡುತ್ತವೆ. ಆ ಕ್ಷಣದಲ್ಲಿ ಪ್ರತ್ಯೇಕ Diffie-Hellman ವಿನಿಮಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದು peer ಸ್ವೀಕರಿಸಲಾಗದ PFS ಗುಂಪು ಇನ್ನೂ ಪರೀಕ್ಷಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ನಂತರ ವಿಫಲವಾಗುವ ಅಗತ್ಯವನ್ನು ಎಂದೂ ಪರೀಕ್ಷಿಸಲಾಗಿಲ್ಲ.
CHILD_SA ಮರುಕೀ ಬೇರೆ ಸಂದೇಶ ಕ್ರಮವಾಗಿದೆ. PFS ಸಂರಚಿಸಲಾದಾಗ, peer ಗಳು ಹೊಸ ಕೀ ವಿನಿಮಯವನ್ನು ನಡೆಸುತ್ತವೆ ಮತ್ತು ಎರಡೂ ಬದಿಗಳು ಸ್ವೀಕರಿಸುವ ಗುಂಪಿನ ಮೇಲೆ, ಜೊತೆಗೆ ಹೊಸ ಸಂಯೋಜನೆಗೆ ESP ಪ್ರಸ್ತಾವನೆಯ ಮೇಲೆ ಒಪ್ಪಬೇಕು. ಅಸಾಮರಸ್ಯ ಕಾಣುವ ಕ್ಷಣ ಅದೇ, ಮತ್ತು ಆದ್ದರಿಂದ ದೋಷವು ಮಾರ್ಗವಲ್ಲದೆ ಪ್ರಸ್ತಾವನೆಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಆದ್ದರಿಂದ “ನಿನ್ನೆ ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು” ಪ್ರಸ್ತಾವನೆಯ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆರಂಭಿಕ ವಿನಿಮಯ ಯಶಸ್ವಿಯಾಯಿತು ಎಂದು ಹೇಳುತ್ತದೆ, ಅದು ನಿಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿತ್ತು.
ವಿಫಲವಾದ ವಿನಿಮಯವನ್ನು ಓದಿ, ಮೊದಲ ping ಅಲ್ಲ
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳಿಂದ ಯಶಸ್ವಿ IKE ದೃಢೀಕರಣ, ಆರಂಭಿಕ CHILD SA ಮತ್ತು ವಿಫಲವಾದ ಬದಲಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ. ನಂತರ ಕ್ರಿಯೆಯನ್ನು ನಿಖರವಾಗಿ ಹೆಸರಿಸಿ: IKE SA ಮರುಕೀ, IKE ಪುನರ್ದೃಢೀಕರಣ ಮತ್ತು CHILD SA ಮರುಕೀ ಮೂರು ವಿಭಿನ್ನ ಘಟನೆಗಳು, ಮತ್ತು “ಹಂತ 2” ಸಾಮಾನ್ಯ ಮಾತಿನಲ್ಲಿ ಅವೆಲ್ಲವನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ.
ಕೆಳಗಿನ ಕ್ಷೇತ್ರಗಳನ್ನು ವಿಫಲವಾದ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಹೋಲಿಸಿ, ಸುರಂಗಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲ.
| ಪದರ | ಹೋಲಿಸಬೇಕಾದ ಮೌಲ್ಯಗಳು |
|---|---|
| IKE | ಆವೃತ್ತಿ, ಗೂಢಲಿಪೀಕರಣ ಮತ್ತು ಸಮಗ್ರತೆ ಅಥವಾ PRF ಜೋಡಣೆ, DH ಗುಂಪು |
| IPsec / CHILD | ESP ಗೂಢಲಿಪೀಕರಣ ಮತ್ತು ಸಮಗ್ರತೆ, ಉದ್ದೇಶಿತ PFS ಅಥವಾ ಕೀ-ವಿನಿಮಯ ಗುಂಪು |
| ಸಂರಕ್ಷಿತ ಸಂಚಾರ | ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ಆಯ್ಕೆಕಾರಕಗಳು, ಜೊತೆಗೆ ನೀತಿ-ಆಧಾರಿತ ಯಾವುದೇ ಆಯ್ಕೆಕಾರಕ ಸೆಟ್ಟಿಂಗ್ |
FortiGate ನಲ್ಲಿ ಆ ಸುರಂಗದ ಹಂತ-2 ಪ್ರಸ್ತಾವನೆ, PFS ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ಸ್ವೀಕೃತ DH ಗುಂಪುಗಳನ್ನು ತೆರೆಯಿರಿ. ಹಿಂದೆ ಸ್ಥಾಪಿತವಾದ ಸಂಪರ್ಕದಿಂದ ಊಹಿಸುವ ಬದಲು ಲೋಡ್ ಆದ ಮೌಲ್ಯಗಳನ್ನು ಓದಿ. GUI ಪುಟದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂರಚನೆಗಿಂತ ದುರ್ಬಲ ಸಾಕ್ಷಿ, ಏಕೆಂದರೆ ಅಪಗ್ರೇಡ್ ನಂತರ ಎರಡೂ ಭಿನ್ನವಾಗಬಹುದು. ನೀವು ಬದಲಿಸಿದ ವಿಭಾಗವನ್ನು ರಫ್ತು ಮಾಡಿ ಮತ್ತು ಟಿಕೆಟ್ ಜೊತೆ ಇರಿಸಿ.
Azure ನ ಡೀಫಾಲ್ಟ್ ನೀತಿಯೂ ಒಂದು ನೀತಿ
ಸಂಪರ್ಕಕ್ಕೆ ಕಸ್ಟಮ್ ನೀತಿ ಲಗತ್ತಿಸದಿರುವುದು Azure ಯಾವುದನ್ನೂ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಎಂದು ಅರ್ಥವಲ್ಲ. ಸಂಪರ್ಕವು ಗೇಟ್‌ವೇಯ ಡೀಫಾಲ್ಟ್ ಪ್ರಸ್ತಾವನೆ-ಗುಂಪಿಗೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಅದು ನಿಮ್ಮ FortiGate ನೀಡುವುದಕ್ಕಿಂತ ವಿಶಾಲ ಅಥವಾ ಸಂಕುಚಿತವಾಗಿರಬಹುದು. ಎರಡೂ ಗುಂಪುಗಳು IKE ಗೆ ಅತಿಕ್ರಮಿಸಿದರೆ ಆದರೆ PFS ಜೊತೆ ESP ಗೆ ಅಲ್ಲ, ನಿಮಗೆ ನಿಖರವಾಗಿ ಈ ವೈಫಲ್ಯ ಮಾದರಿ ಸಿಗುತ್ತದೆ.
ಈ ಓದಲು-ಮಾತ್ರ ನೋಟವು ರಹಸ್ಯಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸದೆ ನಿಜವಾಗಿ ಲಗತ್ತಿಸಿದ ನೀತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesನಿಮ್ಮ ನೈಜ ಸಂಪನ್ಮೂಲ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ. ಸ್ಪಷ್ಟ ನೀತಿ ಬೇಕಾದಾಗ ಅದನ್ನು ಸಂಪರ್ಕ ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಹೊಂದಿಸಿ. ಇದು ಇಡೀ ಗೇಟ್‌ವೇಯ ಸ್ವಿಚ್ ಅಲ್ಲ, ಮತ್ತು ಅದೇ ಗೇಟ್‌ವೇಯ ಇತರ ಸುರಂಗಗಳಿಗೆ ಸದ್ದಿಲ್ಲದೆ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ.
ಪೋರ್ಟಲ್‌ನಲ್ಲಿ, ಆ ಸಂಪರ್ಕದ Configuration ಪುಟವು ಕಸ್ಟಮ್ IPsec/IKE ನೀತಿ ಹೋಗುವ ಸ್ಥಳ. Microsoft ನ ಕಸ್ಟಮ್-ನೀತಿ ಮಾರ್ಗದರ್ಶಿ ಬೆಂಬಲಿತ ನಿಯತಾಂಕಗಳು ಮತ್ತು SKU ಅಗತ್ಯತೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. Azure ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೆ ಒಂದು ಸಂಪೂರ್ಣ ಸಂಯೋಜನೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು IKE ಕ್ಷೇತ್ರಗಳು ಮತ್ತು IPsec ಕ್ಷೇತ್ರಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೂಚಿಸುತ್ತೀರಿ, ಒಂದೊಂದಾಗಿ ಅಲ್ಲ.
PFS ಒಂದು ಅಗತ್ಯ, ತಿರುಗಿಸುವ ಸ್ವಿಚ್ ಅಲ್ಲ
ನಿಮ್ಮ ಭದ್ರತಾ ಮೂಲರೇಖೆ PFS ಅನ್ನು ಕೇಳಿದರೆ, ಪರಿಹಾರವೆಂದರೆ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಎರಡೂ peer ಸ್ವೀಕರಿಸುವ ಗುಂಪು, ಹೊಂದಿಕೆಯಾಗುವ ನೀತಿಯ ಮೂಲಕ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ. ದೋಷ ಮಾಯವಾಗಲು PFS ಆಫ್ ಮಾಡುವುದು ನೀವು ಉಳಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದ ಭದ್ರತಾ ಗುಣವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ನಂತರ ಬೇರೆ ಅಸಾಮರಸ್ಯವಾಗಿ ಮತ್ತೆ ಬರುತ್ತದೆ.
Azure-ನಿರ್ದಿಷ್ಟ ಒಂದು ಬಲೆ: ESP ಗೆ GCM ಆರಿಸಿದಾಗ, ಗೂಢಲಿಪೀಕರಣ ಮತ್ತು ಸಮಗ್ರತೆಯ ಆಯ್ಕೆಗಳು ಒಂದೇ GCM ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು ಒಂದೇ ಕೀ ಉದ್ದವನ್ನು ಹೆಸರಿಸಬೇಕು. GCM ಸೈಫರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಸಮಗ್ರತೆ ಅಲ್ಗಾರಿದಮ್ ಜೊತೆ ಬೆರೆಸುವುದು ಸೇವೆ ತಿರಸ್ಕರಿಸುವ ಸಂಯೋಜನೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ನೀತಿಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದುವವರೆಗೆ ಅದು peer ಅಸಾಮರಸ್ಯದಂತೆ ಕಾಣುತ್ತದೆ.
ಎರಡೂ ತುದಿಗಳು ಬೆಂಬಲಿಸುವ ಮತ್ತು ನಿಮ್ಮ ಅಗತ್ಯ ಅನುಮತಿಸುವ ಅತ್ಯಂತ ಬಲಶಾಲಿ ಸಂಯೋಜನೆಯನ್ನು ಆರಿಸಿ, ನಂತರ ಅದನ್ನು ಬದಲಾವಣೆ-ದಾಖಲೆಯಲ್ಲಿ ಬರೆಯಿರಿ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಆ ದಾಖಲೆಯೊಂದಿಗೆ ಹೋಲಿಸುತ್ತಾರೆ, ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸುರಂಗದ ನೆನಪಿನೊಂದಿಗೆ ಅಲ್ಲ. ಅದರಲ್ಲಿ PFS ಗುಂಪು ಮತ್ತು ESP ಪ್ರಸ್ತಾವನೆಯನ್ನು ಸೇರಿಸಿ, ಕೇವಲ ನೀತಿಯ ಹೆಸರನ್ನಲ್ಲ. ನಂತರ ಯಾರಾದರೂ ಆಡಿಟ್ ಏಕೆ ವಿಫಲವಾಯಿತು ಅಥವಾ ಮರುಕೀ ಏಕೆ ನಿಧಾನ ಎಂದು ಕೇಳಿದಾಗ, ಆ ಸಾಲು ಎರಡೂ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ.
ವಿಫಲವಾದ ವಿನಿಮಯವನ್ನು ಪರಿಶೀಲಿಸಿ
ಬದಲಾವಣೆಯನ್ನು ಮರುಪ್ರಾಪ್ತಿ ಮಾರ್ಗದೊಂದಿಗೆ ನಿಗದಿಪಡಿಸಿ, ಏಕೆಂದರೆ ನೀತಿ ಸಂಪಾದನೆಯು ನೀವು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸುರಂಗವನ್ನು ಅಡ್ಡಿಪಡಿಸಬಹುದು. ಸಂಚಾರ ಹಿಂತಿರುಗಿದ ನಂತರ CHILD_SA ನವೀಕರಣಕ್ಕಾಗಿ ಕಾಯಿರಿ ಅಥವಾ ಅದನ್ನು ಪ್ರಚೋದಿಸಿ ಮತ್ತು ಹೊಸ ಸಂಯೋಜನೆ ಉದ್ದೇಶಿತ PFS ಗುಂಪಿನೊಂದಿಗೆ ಸ್ಥಾಪಿತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಅದರ ಮೂಲಕ ಮುಂದುವರಿಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಎರಡು ತಪ್ಪು ಸುಳಿವುಗಳನ್ನು ಹೆಸರಿಸುವುದು ಯೋಗ್ಯ. SA ಜೀವಿತಾವಧಿಗಳು ಸ್ಥಳೀಯ ವಿಶೇಷಣಗಳು, ಆದ್ದರಿಂದ ಅಸಮ ಮೌಲ್ಯಗಳು ಸಾಮಾನ್ಯ ಮತ್ತು ಅವನ್ನು ಬದಲಿಸುವುದು ಸಮಸ್ಯೆ ಯಾವಾಗ ಕಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸರಿಸುತ್ತದೆ. DPD peer ಜೀವಂತವಾಗಿದೆಯೇ ಎಂದು ಪತ್ತೆ ಮಾಡುತ್ತದೆ; ಅದರ ಕಾಲಮಿತಿ ಹೆಚ್ಚಿಸುವುದು ESP ಅಥವಾ PFS ಆಯ್ಕೆಗಳನ್ನು ಜೋಡಿಸುವುದಿಲ್ಲ.
ಬದಲಾವಣೆಯ ನಂತರ ಮಾತುಕತೆಯ ಫಲಿತಾಂಶ ಮತ್ತು ಮುಂದಿನ ಘಟನೆಯನ್ನು ದಾಖಲಿಸಿ. ಸಂಪರ್ಕ ಈಗ IKE ದೃಢೀಕರಣ ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲು ವಿಫಲವಾದರೆ, ನೀವು ಈಗಷ್ಟೇ ಸಂಪಾದಿಸಿದ IKE ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ, ಮೂಲ CHILD-ನವೀಕರಣ ವೈಫಲ್ಯವನ್ನಲ್ಲ.