Azure VPN NAT ಅತಿಕ್ರಮಿಸುವ VNet ವಿಳಾಸಗಳನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ
ಒಂದೇ ಖಾಸಗಿ ಶ್ರೇಣಿ ಹೊಂದಿರುವ ಎರಡು VNet ಗಳು NAT ಇರುವ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ ಸಂಪರ್ಕಗೊಳ್ಳುವುದಿಲ್ಲ. ಮೊದಲು ಸಂಪರ್ಕದ ಪ್ರಕಾರವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರುಸಂಖ್ಯೆ ಮಾಡಿ ಅಥವಾ ಅನುವಾದ ಉಪನಾಮವನ್ನು ಹೊಂದಿರಿ.
ಎರಡೂ VNet ಗಳು 10.40.1.0/24 ಬಳಸುತ್ತವೆ, ಸುರಂಗಗಳು ಮೇಲೇಳುತ್ತವೆ, ಆದರೆ ಏನೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಎರಡನೇ VPN ಗೇಟ್‌ವೇ ಸೇರಿಸುವುದರಿಂದ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ, ಕಡಿಮೆ ರೂಟ್ ಮೆಟ್ರಿಕ್‌ನಿಂದಲೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸಮಸ್ಯೆ ಮಾರ್ಗ ಆಯ್ಕೆಯಲ್ಲ. ಒಂದೇ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುವ ಎರಡು ವರ್ಕ್‌ಲೋಡ್‌ಗಳು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅಸ್ಪಷ್ಟ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪರಿಶೀಲಿಸಲಾಗದ ಹಿಂತಿರುಗು ಮಾರ್ಗದೊಂದಿಗೆ ಬಿಡುತ್ತವೆ. ಯಾವುದೇ ಅನುವಾದವನ್ನು ಯೋಜಿಸುವ ಮೊದಲು ನೀವು ನಿಜವಾಗಿ ಯಾವ ಸಂಪರ್ಕ ಪ್ರಕಾರವನ್ನು ರಚಿಸಿದ್ದೀರಿ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ, ಏಕೆಂದರೆ ಆ ಒಂದು ಆಯ್ಕೆಯೇ Azure ನ NAT ಸೌಲಭ್ಯವು ಲಭ್ಯವಿದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಈ ಲಕ್ಷಣ ನಿಜವಾಗಿ ನಿಮಗೆ ಏನು ಹೇಳುತ್ತಿದೆ
VNet A ಯಲ್ಲಿನ ಹೋಸ್ಟ್ 10.40.1.10 ಗೆ ಕಳುಹಿಸಿದಾಗ, ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಅದನ್ನು ಎಲ್ಲಿಗಾದರೂ ತೋರಿಸಬಲ್ಲದು. VNet B ಯಲ್ಲೂ 10.40.1.10 ಇದ್ದರೆ, ಆ ವಿಳಾಸವು ಮಾರ್ಗವು ಪ್ರತ್ಯೇಕಿಸಬಲ್ಲ ಗಮ್ಯಸ್ಥಾನವಲ್ಲ; ಅದು ಇಬ್ಬರು ಮಾಲೀಕರಿರುವ ಒಂದೇ ವಿಳಾಸ.
ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ನಿಯೋಜಿಸುವ ಎರಡನೇ ಗೇಟ್‌ವೇ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಇನ್ನೊಂದು ಸುರಂಗವನ್ನು ನೀಡುತ್ತದೆ, ಇನ್ನೊಂದು ವಿಳಾಸವನ್ನಲ್ಲ, ಮತ್ತು ನಕಲಿ ಶ್ರೇಣಿ ಸುರಂಗದ ಒಳಗೆ ಬದಲಾಗದೆ ಚಲಿಸುತ್ತದೆ. ಅದು ನೀವು ಸ್ಥಿರವಾಗಿ ಇರಿಸಬೇಕಾದ ಸಂರಚನೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುತ್ತದೆ. ಅದು ಮಾಡಲಾಗದ್ದು ಒಂದು ವಿಳಾಸವು ಎರಡು ಹೋಸ್ಟ್‌ಗಳನ್ನು ಅರ್ಥೈಸುವಂತೆ ಮಾಡುವುದು.
VPN ಪೀರ್‌ಗಳ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳನ್ನು ಬದಲಾಯಿಸುವುದರಿಂದಲೂ ಏನೂ ಆಗುವುದಿಲ್ಲ. ಆ ವಿಳಾಸಗಳು ಸುರಂಗದ ತುದಿ ಬಿಂದುಗಳನ್ನು ಗುರುತಿಸುತ್ತವೆ, ಆದರೆ ಘರ್ಷಣೆ ಅದರೊಳಗೆ ಸಾಗಿಸಲಾದ ಖಾಸಗಿ ಶ್ರೇಣಿಯಲ್ಲಿದೆ.
NAT ಲಭ್ಯವಿದೆಯೇ ಎಂಬುದನ್ನು ಸಂಪರ್ಕದ ಪ್ರಕಾರ ನಿರ್ಧರಿಸುತ್ತದೆ
Azure VPN Gateway ಗೆ ನಿಜವಾಗಿಯೂ NAT ಸಾಮರ್ಥ್ಯವಿದೆ, ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ಗೇಟ್‌ವೇ SKU ಗಳಲ್ಲಿ ಮಾರ್ಗ ಆಧಾರಿತ IPsec ಅಂತರ-ತಾಣ ಸಂಪರ್ಕಗಳಿಗೆ ದಾಖಲಾಗಿದೆ. ಅದೇ ದಾಖಲೆ VNet-to-VNet ಮತ್ತು point-to-site ಸಂಪರ್ಕಗಳನ್ನು ಹೊರತುಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಸೌಲಭ್ಯವು ಪ್ರತಿ ಗೇಟ್‌ವೇ ಸಂಬಂಧದಲ್ಲೂ ಕಾಣುವ ಚೆಕ್‌ಬಾಕ್ಸ್ ಅಲ್ಲ.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
ಸ್ಥಳೀಯ VNet-to-VNet ಸಹ ಆರಂಭದಿಂದಲೇ VNet ಮತ್ತು ಸ್ಥಳೀಯ ಜಾಲರಿ ಶ್ರೇಣಿಗಳು ಅತಿಕ್ರಮಿಸದಂತೆ ಅಗತ್ಯಪಡಿಸುತ್ತದೆ, ಇದು ಹೊರತುಪಡಿಸುವಿಕೆಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. ಅದೇ ಕಾರಣಕ್ಕೆ VNet ಪೀರಿಂಗ್ ಸಹ ಅತಿಕ್ರಮಣದ ಪರಿಹಾರವಲ್ಲ.
ಜನರು ಸ್ಥಳೀಯ ಪ್ರಕಾರದೊಂದಿಗೆ ಗೊಂದಲಿಸಿಕೊಳ್ಳುವ ಬೆಂಬಲಿತ ಪರ್ಯಾಯವಿದೆ: ಇನ್ನೊಂದು VNet ಅನ್ನು ಸ್ಥಳೀಯ ಜಾಲರಿ ಎಂದು ಮಾದರಿ ಮಾಡಿ ಅದನ್ನು ತಾಣ-ದಿಂದ-ತಾಣ ಸಂಪರ್ಕವಾಗಿ ಜೋಡಿಸಿ. ಅದು ಬೇರೆ ಸಂಪನ್ಮೂಲ ಮತ್ತು ಬೇರೆ ವಿನ್ಯಾಸ, ಆದ್ದರಿಂದ ಮರುನಾಮಕರಣ ಮಾಡಿದ ಸಂಪರ್ಕವನ್ನು ಕೇವಲ ಹೆಸರು ಬದಲಾವಣೆ ಎಂದಲ್ಲ, ಪರಿಶೀಲಿಸಬೇಕಾದ ಬದಲಾವಣೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ಮರುಸಂಖ್ಯೆ ಮಾಡಿ, ಅಥವಾ ಉಪನಾಮವನ್ನು ಹೊಂದಿರುವ ಯಾವುದರಿಂದಲಾದರೂ ಅನುವಾದಿಸಿ
ಎರಡೂ VNet ನಿಮ್ಮವಾದರೆ, ಯೋಜಿತ ಮರುಸಂಖ್ಯೆಯನ್ನು ಅನುವಾದದ ನಿರಂತರ ವೆಚ್ಚದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಮರುಸಂಖ್ಯೆ ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆ, DNS ದಾಖಲೆಗಳು, ಭದ್ರತಾ ನಿಯಮಗಳು ಮತ್ತು ಪ್ರತಿ ಇರುವ ಸಂಪರ್ಕವನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ, ಆದರೆ ನಂತರ ಸಾಮಾನ್ಯವಾಗಿ ಓದಬಹುದಾದ ಜಾಲರಿಯನ್ನು ಬಿಡುತ್ತದೆ. ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಸಬ್‌ನೆಟ್ ಮಾಡಿ, DNS ಬದಲಾವಣೆ ಕೊನೆಯದಾಗಿ. ಅರ್ಧ ಮರುಸಂಖ್ಯೆ ಮಾಡಿದ ಶ್ರೇಣಿ ಎರಡೂ ಆಯ್ಕೆಗಳಿಗಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಆಗ ಎರಡೂ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಮುಂದೆ ಕೋಷ್ಟಕ ಓದುವವರಿಗೆ ಅಧಿಕೃತವೆಂದು ಕಾಣುತ್ತವೆ.
ಮರುಸಂಖ್ಯೆ ಪ್ರಾಯೋಗಿಕವಲ್ಲದೆಡೆ, ಉಪನಾಮಕ್ಕೆ ನಿಜವಾದ ಮಾಲೀಕರಿರುವ ಅನುವಾದಿತ ವಿನ್ಯಾಸವನ್ನು ಬಳಸಿ. VNet A ಯ ಕರೆಗಾರರು VNet B ಯ 10.40.1.10 ಅನ್ನು 10.140.1.10 ಆಗಿ ತಲುಪಬಹುದು, ಆದರೆ ಆ ಉಪನಾಮಕ್ಕೆ ಅನುವಾದಿಸುವ ಸಾಧನ, ಅದರ ಕಡೆಗೆ ಮಾರ್ಗ ಮತ್ತು ಉತ್ತರಕ್ಕೆ ಹೊಂದುವ ವರ್ತನೆ ಬೇಕು. ಕೇವಲ DNS ಗೆ ಸೇರಿಸಿದ ವಿಳಾಸ ಅನುವಾದವಲ್ಲ.
ಎರಡೂ ಶ್ರೇಣಿಗಳನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ದಾಖಲಿಸಿ: ಕರೆಗಾರ ಏನನ್ನು ಡಯಲ್ ಮಾಡುತ್ತಾನೆ, ಗಮ್ಯಸ್ಥಾನವು ಮೂಲವಾಗಿ ಏನನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಯಾವ ಬದಿ ಪ್ರಾರಂಭಿಸಬಹುದು. Azure ನ ಸ್ವಂತ NAT ನಿಯಮಗಳು ತಮ್ಮ SNAT ಮ್ಯಾಪಿಂಗ್‌ಗಳಿಗೆ ಹಿಮ್ಮುಖ ಅನುವಾದವನ್ನು ಒಳಗೊಂಡಿವೆ, ಆದ್ದರಿಂದ ನೀವು ಹೊಂದುವ DNAT ನಿಯಮವನ್ನು ಕೈಯಿಂದ ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ಆ ಅನುಕೂಲ ಈ ಸೌಲಭ್ಯ ಬೆಂಬಲಿಸುವ ಸಂಪರ್ಕ ಪ್ರಕಾರಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ಏನು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ
ಬಳಕೆದಾರ-ನಿರ್ಧರಿತ ಮಾರ್ಗ ಅಥವಾ ರೂಟ್ ಮೆಟ್ರಿಕ್ ಕಾಣೆಯಾದ ವಿಳಾಸ ಭೇದವನ್ನು ಸೃಷ್ಟಿಸಲಾರವು. ಎರಡೂ ಇನ್ನೂ ಅಸ್ಪಷ್ಟ ಗಮ್ಯಸ್ಥಾನದ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಕೋಷ್ಟಕ ಇಷ್ಟಪಡುವ ಮುಂದಿನ ಹಾಪ್‌ಗೆ ತಲುಪುತ್ತದೆ.
ನಕಲಿ ಶ್ರೇಣಿಯನ್ನು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಪ್ರಿಫಿಕ್ಸ್ ಆಗಿ ರೂಟ್ ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರಿಸುವುದು ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಒಂದು ಹೆಜ್ಜೆ ಮುಂದಕ್ಕೆ ಸರಿಸುತ್ತದೆ. ಅದು ಇನ್ನೊಂದು ದಿಕ್ಕನ್ನು ಮುರಿಯುವ ಪ್ರವೃತ್ತಿ ಹೊಂದಿದೆ, ಅಲ್ಲಿ ಉತ್ತರಕ್ಕೆ ಈಗ ಎರಡು ಸಂಭಾವ್ಯ ಮೂಲಗಳಿವೆ.
ಎರಡೂ ದಿಕ್ಕುಗಳ ಸಂಚಾರದೊಂದಿಗೆ ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸಿ
ಸುರಂಗ ಸ್ಥಿತಿಯಿಂದ ಅಲ್ಲ, ಪ್ರತಿ ಬದಿಯಿಂದ ಹೊಸ ಅನುಮತಿಸಿದ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ವಿನ್ಯಾಸವನ್ನು ಸಾಬೀತುಪಡಿಸಿ. ಸಂಪರ್ಕಗೊಂಡ IPsec ಸುರಂಗವು ಪೀರ್‌ಗಳು ಕ್ರಿಪ್ಟೋಗ್ರಫಿ ಬಗ್ಗೆ ಒಪ್ಪುತ್ತವೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಗಮ್ಯಸ್ಥಾನಗಳು ಪ್ರತ್ಯೇಕವಾದವೇ ಎಂದು ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ನಂತರ ನಿರಾಕರಿಸಿದ ಮಾರ್ಗಗಳನ್ನು ಚಲಾಯಿಸಿ: ತಲುಪಲಾಗದೇ ಉಳಿಯಬೇಕಾದ ವಿಳಾಸ, ಮತ್ತು ನೀತಿಯು ತಡೆಯಬೇಕಾದ ಸೇವೆ. ಎರಡೂ ಇನ್ನೂ ಯಶಸ್ವಿಯಾದರೆ, ಅನುವಾದವು ವಿನ್ಯಾಸದ ಉದ್ದೇಶಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿದೆ.
ಹೊಂದಾಣಿಕೆಯನ್ನು ನಂತರ ವಿವರಿಸುವ ಸಂಗತಿಗಳೊಂದಿಗೆ ಮುಗಿಸಿ: ಮೂಲ ಶ್ರೇಣಿ, ಪ್ರಸ್ತುತಪಡಿಸಿದ ಶ್ರೇಣಿ, ಅನುವಾದಿಸುವ ಸಾಧನ, ಮತ್ತು ಪ್ರತಿ ಬದಿ ಪ್ರಾರಂಭಿಸಬಹುದಾದ ದಿಕ್ಕು. ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಇಲ್ಲದಿದ್ದರೆ, ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ಒಂದೇ ಹೆಸರು ಹಂಚಿಕೊಳ್ಳುವ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಏಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಯಾರಿಗೂ ನೆನಪಿಲ್ಲದ ಜಾಲರಿಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತಾರೆ.