AWS ನಿಂದ Azure ಸೈಟ್ VPN: ಮೊದಲು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬರೆಯಿರಿ
ಎರಡು ಕ್ಲೌಡ್‌ಗಳ ನಡುವಿನ ಜೋಡಿತ ಟನೆಲ್ ಪ್ರತಿ ವರ್ಕ್‌ಲೋಡ್ ಸಬ್‌ನೆಟ್ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ರೂಟ್ ಮಾಡುವವರೆಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಯೋಜನೆಯನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ, ನಂತರ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಟನೆಲ್ ಮೇಲೆ ಬರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಹಾಗೆಯೇ ಆಗುತ್ತದೆ, ಏಕೆಂದರೆ IKE ಗೆ ಹೊಂದುವ ಪ್ರಸ್ತಾವಗಳು ಮತ್ತು ತಲುಪಬಹುದಾದ ಪೀರ್ ವಿಳಾಸ ಮಾತ್ರ ಬೇಕು. ನಂತರ ವಿಫಲವಾಗುವುದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ: AWS ವರ್ಕ್‌ಲೋಡ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಟನೆಲ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದರೆ Azure ಬದಿಯಲ್ಲಿ 10.10.0.0/16 ಗೆ ಹೇಗೆ ಉತ್ತರಿಸಬೇಕೆಂದು ಯಾರಿಗೂ ಗೊತ್ತಿಲ್ಲ, ಅಥವಾ Azure ಮಾರ್ಗವು ವರ್ಕ್‌ಲೋಡ್ ಸಬ್‌ನೆಟ್ ಬಳಸದ ಕೋಷ್ಟಕದಲ್ಲಿದೆ. ಯಾವುದೇ ಕನ್ಸೋಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಮಾರ್ಗ ಯೋಜನೆ ಬರೆಯಿರಿ, ಮತ್ತು ಟನೆಲ್ ಕೆಲಸದ ಅತ್ಯಂತ ಕಡಿಮೆ ಆಸಕ್ತಿಯ ಭಾಗವಾಗುತ್ತದೆ.
ಹಂತ 1: ವಿಳಾಸ ಯೋಜನೆಯನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ
ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿ. AWS ವರ್ಕ್‌ಲೋಡ್ 10.10.0.0/16 ಒಳಗೆ 10.10.1.20 ನಲ್ಲಿದೆ ಮತ್ತು 10.20.0.0/16 ಒಳಗೆ 10.20.1.30 ನಲ್ಲಿರುವ Azure ಸೇವೆಗೆ TCP 443 ಬೇಕು. ಎರಡೂ ಶ್ರೇಣಿಗಳು ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೊಳ್ಳಬಾರದು, ಮತ್ತು ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆ ಸೇವಾ ಜೋಡಿ, ಟನೆಲ್ ಅಲ್ಲ.
ಬೇರೆ ಯಾವುದಕ್ಕೂ ಮೊದಲು ಆ ನಾಲ್ಕು ಅಂಶಗಳನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಮುಂದಿನ ಹಂತವೂ ಅವುಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲ್ಪಡುತ್ತದೆ.
ಹಂತ 2: ಪ್ರತಿ ತುದಿಯ ಮಾಲೀಕ ಗೇಟ್‌ವೇ ಹೆಸರಿಸಿ
AWS Site-to-Site VPN ವರ್ಚುವಲ್ ಪ್ರೈವೇಟ್ ಗೇಟ್‌ವೇ ಅಥವಾ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಮೇಲೆ ಕೊನೆಗೊಳ್ಳಬಹುದು, ಮತ್ತು ಇವು ಬೇರೆ ಬೇರೆ ರೂಟಿಂಗ್ ಮಾಲೀಕರು. Azure ತನ್ನ ನಿರ್ವಹಿತ VPN Gateway ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ ಗ್ರಾಹಕರು ತಾವೇ ನಡೆಸುವ VM ಆಧಾರಿತ ಉಪಕರಣಗಳನ್ನು ನೀಡುತ್ತದೆ. ನಿಮ್ಮ ಬಳಿ ಯಾವ ಜೋಡಿ ಇದೆ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸಂಯೋಜನೆಯಲ್ಲಿ ಮುಂದಿನ ಹಾಪ್ ಬೇರೆಯಾಗಿರುತ್ತದೆ.
ನಿರ್ವಹಿತ ಗೇಟ್‌ವೇಗೆ, ಊಹಿಸಿದ ಖಾಸಗಿ ಉಪಕರಣ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ಮಾರ್ಗವನ್ನು ನಕಲಿಸಬೇಡಿ. ಉಪಕರಣಕ್ಕೆ, ಕ್ಲೌಡ್ ಮಾರ್ಗ ಪ್ರಸರಣವು ಅತಿಥಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಂರಚಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ.
ಇಲ್ಲಿ ತಪ್ಪು ಮಾಡಿದರೆ ಪೂರ್ಣವಾಗಿ ಕಾಣುವ ಯೋಜನೆ ಸಿಗುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಎಂದಿಗೂ ಉತ್ತರಿಸದ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ.
ಹಂತ 3: ಪ್ರತಿ ವರ್ಕ್‌ಲೋಡ್ ನಿಜವಾಗಿ ಬಳಸುವ ಮಾರ್ಗ ಬರೆಯಿರಿ
ಕೆಳಗಿನ ಪ್ರತಿ ಗಡಿಯೂ ಪ್ರತ್ಯೇಕ ಹುಡುಕಾಟ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿರುವ ಮಾರ್ಗ ಪ್ಯಾಕೆಟ್‌ಗೆ ಮಾರ್ಗವಲ್ಲ. ಟನೆಲ್ ಜೀವಂತವಾಗುವ ಮೊದಲು ಕೋಷ್ಟಕವನ್ನು ನಿಮ್ಮ ಮೌಲ್ಯಗಳಿಂದ ತುಂಬಿಸಿ.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS ನಲ್ಲಿ, BGP ಅಥವಾ ಟನೆಲ್ ಆರೋಗ್ಯವಾಗಿದ್ದರೂ ವರ್ಕ್‌ಲೋಡ್ ಸಬ್‌ನೆಟ್‌ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ನೀವೇ ನವೀಕರಿಸಬೇಕು; ರೂಟಿಂಗ್ ಅವಲೋಕನ ಅದನ್ನು ಸಂಪರ್ಕದ ಭಾಗವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. Azure ನಲ್ಲಿ, ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ಮಾರ್ಗ ಕೋಷ್ಟಕವು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಅಲ್ಲ, ಸಬ್‌ನೆಟ್‌ಗೆ ಸಂಬಂಧಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವನ್ನು VNet ಬ್ಲೇಡ್‌ನಲ್ಲಿ ಅಲ್ಲ, ವರ್ಕ್‌ಲೋಡ್ NIC ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ.
ನಿರ್ವಹಿತ Azure ಗೇಟ್‌ವೇ ಗೇಟ್‌ವೇ ಪ್ರಸರಣದ ಮೂಲಕ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಕಲಿಯಬಹುದು, ಮತ್ತು UDR ಆ ನಿರ್ಣಯವನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು. ಕಾರಣವಿದ್ದಾಗ UDR ಸೇರಿಸಿ, ಅಭ್ಯಾಸದಿಂದಲ್ಲ. ಸೇರಿಸಿದರೆ, ಉಪಕರಣ ವಿಳಾಸ ಕಲ್ಪಿಸುವ ಬದಲು ಗೇಟ್‌ವೇ VPN ಮಾರ್ಗಕ್ಕೆ ಪ್ರಕಟಿಸುವ ಮುಂದಿನ ಹಾಪ್‌ಗೆ ನಿರ್ದೇಶಿಸಿ. ನಂತರ NIC ನಲ್ಲಿನ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗಗಳನ್ನು ಮತ್ತೆ ಓದಿ, ಏಕೆಂದರೆ ನಿರ್ಣಯ ನಿಜವಾಗಿ ಅಲ್ಲಿಯೇ ತೆಗೆದುಕೊಳ್ಳಲ್ಪಡುತ್ತದೆ.
ಹಂತ 4: ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿಸಿ
BGP ಗೆ, ಪ್ರತಿ ಬದಿಯು ಘೋಷಿಸುವುದನ್ನು ಇನ್ನೊಂದು ಬದಿ ನಿಜವಾಗಿ ಕಲಿತದ್ದಕ್ಕೆ ಹೋಲಿಸಿ, ಪ್ರಿಫಿಕ್ಸ್ ಪ್ರಿಫಿಕ್ಸ್ ಆಗಿ. ಸ್ಥಿರ ರೂಟಿಂಗ್‌ಗೆ, ಸಂರಚಿಸಿದ ದೂರದ ಶ್ರೇಣಿಗಳನ್ನು ಹಂತ 3 ರಲ್ಲಿ ಬರೆದ ವರ್ಕ್‌ಲೋಡ್ ಮಾರ್ಗಗಳಿಗೆ ಹೋಲಿಸಿ.
ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯಲ್ಲಿ ಒಪ್ಪಿದ IKE ಸಂಬಂಧವು ಯಾವುದೇ ಬದಿ 10.10.0.0/16 ಅಥವಾ 10.20.0.0/16 ಕಲಿತಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ನೀವು ಯೋಜಿಸಿದ /16 ಬದಲು ಒಂದೇ /24 ಘೋಷಿಸುತ್ತಿದ್ದರೂ ಎರಡು ಟನೆಲ್‌ಗಳು ಮೇಲಿರಬಹುದು. ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, ಟನೆಲ್ ಸ್ಥಿತಿಯಲ್ಲಿ ಅಲ್ಲ. ಅಸಂಗತಿ ನಂತರ ಒಂದು ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಒಂದು ಎಂದಿಗೂ ಉತ್ತರಿಸದ ಸಬ್‌ನೆಟ್ ಆಗಿ ಕಾಣಿಸುತ್ತದೆ.
ಹಂತ 5: ನಿಜವಾದ ಮೂಲದಿಂದ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ
AWS ಭದ್ರತಾ ಗುಂಪುಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ACL, Azure NSG, ಮತ್ತು ಮಾರ್ಗದಲ್ಲಿನ ಯಾವುದೇ ಉಪಕರಣ ಫಿಲ್ಟರ್‌ನಲ್ಲಿ ಉದ್ದೇಶಿತ ಹರಿವನ್ನು ಅನುಮತಿಸಿ. ನಂತರ 10.10.1.20 ರಿಂದ ಅನುಮೋದಿತ ಸೇವಾ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಒಂದು ಸಂಪರ್ಕ ತೆರೆದು ಉತ್ತರ ಅದೇ ಮೂಲಕ್ಕೆ ಮರಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಕ್ಲೌಡ್ ಭದ್ರತಾ ಗುಂಪುಗಳು ಮತ್ತು NSG ಎರಡೂ stateful, ಆದ್ದರಿಂದ ನಿರಾಕರಿಸಲ್ಪಟ್ಟ ಹಿಂತಿರುಗುವ ಪ್ಯಾಕೆಟ್ ರೂಟಿಂಗ್‌ನ ಲಕ್ಷಣ, ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಬರೆಯಲು ಮರೆತ ನಿಯಮವಲ್ಲ.
ಯಾವುದೇ ಗೇಟ್‌ವೇಯಿಂದ ping ಏನನ್ನೂ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇ ವಿಳಾಸಕ್ಕೆ ICMP ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ, ವರ್ಕ್‌ಲೋಡ್‌ಗೆ ಬೇಕಾದ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾದ TCP ಸೇವೆಯನ್ನಲ್ಲ.
ರೋಲ್‌ಬ್ಯಾಕ್ ಮತ್ತು ದಾಖಲೆಗಳು
ಟನೆಲ್ ಗುರುತಿಸುವಿಕೆಗಳ ಪಕ್ಕದಲ್ಲಿ ಮಾರ್ಗ ಮಾಲೀಕರನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ಬದಲಾವಣೆಗೆ ಮೊದಲಿನ ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳನ್ನು ಉಳಿಸಿ. ಬದಲಾವಣೆಯನ್ನು ತೆಗೆಯಬೇಕಾದರೆ, ಟನೆಲ್ ಒಡೆಯುವ ಮೊದಲು ವರ್ಕ್‌ಲೋಡ್ ಮಾರ್ಗಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಇದರಿಂದ ಯಾವುದೇ ಸಬ್‌ನೆಟ್ ಇನ್ನಿಲ್ಲದ ಮುಂದಿನ ಹಾಪ್‌ಗೆ ತೋರಿಸುತ್ತಿರದು.
ಆಗ ಮುಂದಿನ ಸಬ್‌ನೆಟ್ ಸ್ಥಳಾಂತರ ಅಥವಾ spoke ಸೇರಿಸುವಿಕೆಗೆ ನವೀಕರಿಸಲು ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳವಿರುತ್ತದೆ, ಎಂದಿಗೂ ಸ್ವಂತವಲ್ಲದ ಮಾರ್ಗದ ದೋಷವನ್ನು ಹೊತ್ತುಕೊಂಡು ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್‌ಗೆ ಬದಲಾಗಿ.