ಪೀರ್ ಮಾಡಿದ Azure VNet ಗೆ ತನ್ನದೇ VPN ಗೇಟ್ವೇ ಬೇಕೇ?
ಪೀರ್ ಮಾಡಿದ VNet ಬೆಂಬಲಿತ SKU ಮತ್ತು ಪ್ರತಿ ಪೀರಿಂಗ್ ದಿಕ್ಕಿನಲ್ಲಿ ಒಂದು ಸೆಟ್ಟಿಂಗ್ನೊಂದಿಗೆ ಹಬ್ನ VPN ಗೇಟ್ವೇ ಬಳಸಬಹುದು. ಪೀರಿಂಗ್ ಸ್ಥಿತಿಯಲ್ಲ, ಪರಿಣಾಮಕಾರಿ ರೂಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಹೊಸ spoke VNet ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, hub ಬಳಿ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುವ site-to-site ಗೇಟ್ವೇ ಇದೆ, ಮತ್ತು ಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆ ಎಂದರೆ ಎರಡನೇ ಗೇಟ್ವೇಗೆ ನೀವು ಹಣ ಕೊಡಬೇಕೇ. ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲ: ಗೇಟ್ವೇ ಟ್ರಾನ್ಸಿಟ್ spoke ಗೆ peering ಮೂಲಕ hub ನ ಗೇಟ್ವೇ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ peering ಸ್ಥಿತಿ ಬ್ಯಾಡ್ಜ್ನಿಂದ ಕಾಣುವುದಿಲ್ಲ. Peering ಸಂಪರ್ಕ ಮತ್ತು ಬೇರೊಬ್ಬರ ಗೇಟ್ವೇ ಬಳಸುವ ಅನುಮತಿ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಆದ್ದರಿಂದ ಈಗಾಗಲೇ ಒಂದರಿಂದೊಂದು ping ಮಾಡಬಲ್ಲ ಎರಡು VM VPN ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಮೊದಲ ಷರತ್ತು: ಗೇಟ್ವೇ, ಮತ್ತು spoke ನಲ್ಲಿ ಅದರ ಕೊರತೆ
Azure Basic ಹೊರತುಪಡಿಸಿ ಇತರ VPN Gateway SKU ಗಳಿಗೆ ಗೇಟ್ವೇ ಟ್ರಾನ್ಸಿಟ್ ಬೆಂಬಲಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾದೇಶಿಕ ಹಾಗೂ ಜಾಗತಿಕ peering ಎರಡೂ ಅದನ್ನು ಸಾಗಿಸಬಲ್ಲವು. spoke ತನ್ನದಲ್ಲದ ಗೇಟ್ವೇ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ತನ್ನದೇ ಗೇಟ್ವೇ ಹೊಂದಲು ಸಾಧ್ಯವಿಲ್ಲ: spoke ನಲ್ಲಿ ಈಗಾಗಲೇ ಗೇಟ್ವೇ ಇದ್ದರೆ, ಅಥವಾ ದೂರದ ಗೇಟ್ವೇ ಆಯ್ಕೆ ಈಗಾಗಲೇ ಆಯ್ಕೆಯಾಗಿದ್ದರೆ, ನೀವು ಬಯಸುವ ಟ್ರಾನ್ಸಿಟ್ ಸೆಟ್ಟಿಂಗ್ ಲಭ್ಯವಾಗುವುದಿಲ್ಲ ಅಥವಾ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವುದಿಲ್ಲ. ಏನನ್ನೂ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಇದನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನಿಷ್ಕ್ರಿಯ ಚೆಕ್ಬಾಕ್ಸ್ ಲಕ್ಷಣ, ದೋಷವಲ್ಲ. ಮೊದಲು SKU ಮತ್ತು ಇರುವ ಗೇಟ್ವೇ ಓದಿ, ನಂತರ peering ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನೋಡಿ.
ಆಯ್ಕೆ ಕಾಣಿಸುವಂತೆ ಮಾಡಲು ಇರುವ spoke ಗೇಟ್ವೇ ಅನ್ನು ಅದರ ಮೇಲೆ ಏನು ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ತಿಳಿಯುವವರೆಗೆ ಅಳಿಸಬೇಡಿ. ಸ್ಥಳಾಂತರ ಕ್ರಮ ಚೆಕ್ಬಾಕ್ಸ್ಗಿಂತ ಮುಖ್ಯ.
ಎರಡನೇ ಷರತ್ತು: ಪ್ರತಿ peering ದಿಕ್ಕಿನಲ್ಲಿ ಒಂದು ಸೆಟ್ಟಿಂಗ್
peering ಎರಡು ಆಬ್ಜೆಕ್ಟ್ಗಳು, ಪ್ರತಿ VNet ನಲ್ಲಿ ಒಂದು, ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ಆ ಜೋಡಿಯ ಬೇರೆ ಬೇರೆ ಬದಿಗಳಲ್ಲಿವೆ. hub ನಿಂದ spoke ಕಡೆಗಿನ peering, hub ಗೇಟ್ವೇ spoke ಗೆ ಸೇವೆ ನೀಡಲು ಅನುಮತಿಸಬೇಕು; spoke ನಿಂದ hub ಕಡೆಗಿನ peering, hub ನ ಗೇಟ್ವೇ ಸ್ವೀಕರಿಸಬೇಕು. Microsoft ನ ಗೇಟ್ವೇ-ಟ್ರಾನ್ಸಿಟ್ ಮಾರ್ಗದರ್ಶಿ ದಿಕ್ಕಿನ ಪ್ರಕಾರ ಅವುಗಳಿಗೆ ಹೆಸರಿಡುತ್ತದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಇರಿಸಲು ಅದೊಂದೇ ದಾರಿ:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote ಎಂಬ ಲೇಬಲ್ ಇರುವ ನಿಯಂತ್ರಣ ನೀವು ಯಾವ VNet ನ peering ಸಂಪಾದಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅರ್ಥ ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪದವಲ್ಲ, ದಿಕ್ಕನ್ನು ಓದಿ. ಎರಡೂ ಬದಿಗಳನ್ನು ಸೆಟ್ ಮಾಡಿ, ಉಳಿಸಿ, ಮತ್ತು peering ಎರಡೂ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಮೂರನೇ ಷರತ್ತು: ವಿಳಾಸ ಸ್ಥಳ ಮತ್ತು ಅನುಮತಿ ಗಡಿಗಳು
ಟ್ರಾನ್ಸಿಟ್ ಒಂದೇ ಗಮ್ಯಸ್ಥಾನ ಪ್ರಿಫಿಕ್ಸ್ ಎರಡು ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಅರ್ಥೈಸುವಂತೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ hub, spoke ಮತ್ತು ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನ ವ್ಯಾಪ್ತಿಗಳು ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಕೆಲಸ ಮಾಡುವ ಮೊದಲು ಪ್ರತ್ಯೇಕವಾಗಿರಬೇಕು. VNet ಗಳು ವಿವಿಧ ಚಂದಾದಾರಿಕೆಗಳಲ್ಲಿ ಅಥವಾ ವಿವಿಧ ಟೆನೆಂಟ್ಗಳಲ್ಲಿ ಸಹ ಇರಬಹುದು; ಅದು ನಿಷೇಧವಲ್ಲ, ಆದರೆ ಪ್ರತಿ peering ರಚಿಸುವ ಅಥವಾ ನವೀಕರಿಸುವ ಗುರುತಿಗೆ ಆ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಅಗತ್ಯ ಅನುಮತಿಗಳು ಬೇಕು. ಚಂದಾದಾರಿಕೆಗಳ ನಡುವಿನ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚಾಗಿ ಅನುಮತಿಯಿಂದ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ದೋಷವನ್ನು ಟೋಪೋಲಜಿ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಓದುವುದು ಸುಲಭ.
ಬದಲಾವಣೆಗೆ ಮೊದಲು ವ್ಯಾಪ್ತಿಗಳು ಮತ್ತು ಮಾಲೀಕರನ್ನು ಬರೆಯಿರಿ. ಎರಡರಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಊಹಿಸುವುದು ಸಂಪರ್ಕಗೊಳ್ಳುವ ಆದರೆ ಏನನ್ನೂ ರೂಟ್ ಮಾಡದ peering ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
peering ಸ್ಥಿತಿಯಿಂದಲ್ಲ, ಪರಿಣಾಮಕಾರಿ ರೂಟ್ಗಳಿಂದ ಪರಿಶೀಲಿಸಿ
spoke ವರ್ಕ್ಲೋಡ್ನ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿನ ಪರಿಣಾಮಕಾರಿ ರೂಟ್ಗಳನ್ನು ನೋಡಿ ಮತ್ತು ನಿಜವಾದ ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಹುಡುಕಿ. ಸಬ್ನೆಟ್ನ ರೂಟ್ ಟೇಬಲ್ ಮತ್ತು ಗೇಟ್ವೇ ರೂಟ್ ಪ್ರಸಾರ ನಿಷ್ಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ರೂಟ್ ಅಥವಾ ತಪಾಸಣಾ ಸಾಧನವು peering ಫ್ಲ್ಯಾಗ್ಗಳು ಸೂಚಿಸುವ ಮಾರ್ಗವನ್ನು ಮೀರಿಸಬಹುದು. ನಂತರ ಇನ್ನೊಂದು ದಿಕ್ಕನ್ನು ಖಚಿತಪಡಿಸಿ: ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ site-to-site ಸಂಪರ್ಕದ ಮೂಲಕ spoke ಪ್ರಿಫಿಕ್ಸ್ ತಲುಪುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿದಿರಬೇಕು, ಅದು ಕಲಿತ ಜಾಹೀರಾತುಗಳ ಮೂಲಕವಾಗಲಿ ಅಥವಾ ಸ್ಪಷ್ಟ ರೂಟ್ ಮತ್ತು ಗ್ರಾಹಕ ಸಾಧನದಲ್ಲಿ ಹೊಂದುವ ಸಂರಕ್ಷಿತ-ನೆಟ್ವರ್ಕ್ ನಮೂದಿನ ಮೂಲಕವಾಗಲಿ. ಪ್ರಿಫಿಕ್ಸ್ ಯಾವುದೇ ಬದಿಯಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಬದಲಾಯಿಸಬೇಕಾದದ್ದು peering ಫ್ಲ್ಯಾಗ್ಗಳಲ್ಲ.
spoke ವರ್ಕ್ಲೋಡ್ನಿಂದ ಒಂದು ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಿ. VPN ಗೇಟ್ವೇ ಅಥವಾ hub VM ನಿಂದ ಪರೀಕ್ಷೆ ಬೇರೆ ಮೂಲ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಬೇರೆ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತದೆ.
topology point-to-site ಕ್ಲೈಂಟ್ಗಳಿಗೂ ಸೇವೆ ನೀಡಿದರೆ, ಅವರ ಸ್ಥಾಪಿತ ರೂಟ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾನ್ಯಗೊಳಿಸಿ. topology ಬದಲಾವಣೆಯ ನಂತರ Windows ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಬೇಕಾಗಬಹುದು, ಮತ್ತು ಅದು ಗೇಟ್ವೇ ಹಂಚಿಕೆ ವಿಫಲವಾದ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಕ್ಲೈಂಟ್ ರೂಟಿಂಗ್ ಕೆಲಸ.
ಗೇಟ್ವೇ ಹಂಚಿಕೊಳ್ಳುವುದು ಏನನ್ನು ನೀಡುವುದಿಲ್ಲ
ಗೇಟ್ವೇ ಟ್ರಾನ್ಸಿಟ್ ರೂಟಿಂಗ್ ಸೌಲಭ್ಯ, ಅಧಿಕಾರವಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪುಗಳು, ಸ್ಥಳೀಯ ಫಿಲ್ಟರ್ಗಳು ಮತ್ತು ಸೇವಾ-ಹಂತದ ನಿಯಮಗಳು ಇನ್ನೂ spoke ವರ್ಕ್ಲೋಡ್ ಎಲ್ಲಿಗೆ ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಹಂಚಿದ ಟನೆಲ್ ಅದರ ಹಿಂದಿನ ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿರ್ದಿಷ್ಟ ಮೂಲದಿಂದ ಗಮ್ಯಸ್ಥಾನದ ಸೇವೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ.
peering ಕೂಡ ಜನರು ನಿರೀಕ್ಷಿಸುವಂತೆ ಪಾರಗಾಮಿಯಲ್ಲ. ಇನ್ನೊಂದು spoke ಅಥವಾ ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಸೇರಿಸುವುದು ಅದರ ಸ್ವಂತ ರೂಟಿಂಗ್ ಮತ್ತು ಪ್ರವೇಶ ಅಗತ್ಯಗಳನ್ನು ತರುತ್ತದೆ, ಅವನ್ನು ಇರುವ ಟ್ರಾನ್ಸಿಟ್ ಸೆಟ್ಟಿಂಗ್ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.