Azure UDR ನಿಂದ VPN ಗೇಟ್‌ವೇಗೆ: ಒಂದು ಗಮ್ಯಸ್ಥಾನ, ಎಲ್ಲಾ ನಿರ್ಗಮನವಲ್ಲ

ನೀವು ಒಂದು ಬಾಹ್ಯ ಪ್ರಿಫಿಕ್ಸ್‌ಗಾಗಿ ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುತ್ತೀರಿ, ಅದನ್ನು VPN ಗೇಟ್‌ವೇಗೆ ತೋರಿಸುತ್ತೀರಿ, ಮತ್ತು ಸಂಚಾರವು ಇನ್ನೂ Azure ನ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ. ಅಥವಾ ಅದು ಸರಿಯಾಗಿ ಹೊರಹೋಗುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಎಂದಿಗೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ. ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಒಂದೇ ತಪ್ಪಿನಿಂದ ಬರುತ್ತವೆ: Azure ನ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಇಡೀ ವಿನ್ಯಾಸ ಎಂದು ಪರಿಗಣಿಸುವುದು. ಮಾರ್ಗ ಕೋಷ್ಟಕವು Azure ಒಳಗೆ ಪ್ಯಾಕೆಟ್ ಯಾವ ನಿರ್ಗಮನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. ಸುರಂಗದ ನಂತರ ಅದಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಹೇಗೆ ಹಿಂತಿರುಗುತ್ತದೆ ಎಂಬುದು ನೀವು ನಿರ್ಮಿಸಬೇಕಾದ ಎರಡನೇ ಅರ್ಧ.

ಮುಂದಿನ ಹಾಪ್ ಒಂದು ಗೇಟ್‌ವೇ, ಸಾಧನದ IP ಅಲ್ಲ

UDR ಹೊಂದಿಕೆಯಾಗುವ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಮುಂದಿನ-ಹಾಪ್ ಪ್ರಕಾರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು VirtualNetworkGateway ಒಂದು ಪ್ರಕಾರ, ವಿಳಾಸವಲ್ಲ. ಜನರು ಗೇಟ್‌ವೇಯ ಖಾಸಗಿ IP ಅನ್ನು VirtualAppliance ಮಾರ್ಗಕ್ಕೆ ಅಂಟಿಸಿ ನಂತರ ಏಕೆ ಏನೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂದು ಆಶ್ಚರ್ಯಪಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಆ ಪ್ರಕಾರವು ಬದಲಿಗೆ NIC ಅಥವಾ ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. Microsoft ನ ರೂಟಿಂಗ್ ದಾಖಲೆಗಳು ಸಹ ಗೇಟ್‌ವೇ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಗೇಟ್‌ವೇ VPN ಗೇಟ್‌ವೇ ಆಗಿರುವ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ. ExpressRoute, Route Server ಮತ್ತು Virtual WAN ಹಬ್ ಆ ಆಯ್ಕೆಯಿಂದ ಉದ್ದೇಶಿಸಲ್ಪಡುವುದಿಲ್ಲ.

ಮಾರ್ಗ ಬರೆಯುವ ಮೊದಲು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ವಿನ್ಯಾಸವು ಹಬ್ ಮೂಲಕ ರೂಟ್ ಮಾಡಿದರೆ, ಮಾರ್ಗವು ನೀವು ಸಂಪಾದಿಸುತ್ತಿರುವ ಸ್ಪೋಕ್‌ನದಲ್ಲ, ಹಬ್‌ನ ರೂಟಿಂಗ್ ಮಾಲೀಕನದು.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವನ್ನು ಓದಿ

Azure ಸಿಸ್ಟಂ ಮಾರ್ಗಗಳು, BGP ಮೂಲಕ ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಮತ್ತು UDR ಗಳನ್ನು ಪ್ರತಿ NIC ಗೆ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಿ ಸಂಯೋಜಿಸುತ್ತದೆ, ಮತ್ತು ಉದ್ದವಾದ ಹೊಂದಿಕೆಯಾಗುವ ಪ್ರಿಫಿಕ್ಸ್ ಎಲ್ಲಿಂದ ಬಂದಿದ್ದರೂ ಗೆಲ್ಲುತ್ತದೆ. ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ, UDR BGP ಮಾರ್ಗವನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಈ ಕ್ರಮವೇ ಹಿಂದಿನ ಪ್ರಯೋಗದ ಹಳೆಯ UDR ಸುರಂಗದ ಮೂಲಕ ನೀವು ಈಗಷ್ಟೇ ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮೀರಿಸಬಹುದಾದ ಕಾರಣ.

ಮೊದಲು ಪರಿಣಾಮಕಾರಿ ಕೋಷ್ಟಕವನ್ನು ನೋಡಿ, ನಂತರ ನೀವು ಮಾರ್ಗವನ್ನು ಸೇರಿಸುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಬದಲಾಯಿಸುತ್ತಿದ್ದೀರಾ ಎಂದು ನಿರ್ಧರಿಸಿ:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

ಪ್ರಿಫಿಕ್ಸ್ ಜೊತೆಗೆ ಮೂಲ ಕಾಲಮ್ ಅನ್ನೂ ಓದಿ. ಸರಿಯಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ತಪ್ಪು ಮೂಲವಿರುವ ಮಾರ್ಗವು ಯಾವ ವಸ್ತುವನ್ನು ಸಂಪಾದಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಮೊದಲನೆಯದಕ್ಕೆ ಸೋಲುವ ಎರಡನೇ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ನಿಜವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಸಬ್‌ನೆಟ್ ವಿರುದ್ಧ ಮಾರ್ಗವನ್ನು ಬರೆಯಿರಿ

ಫೋರಮ್ ಪೋಸ್ಟ್‌ನಿಂದ ನಕಲಿಸಿದ ಸಾರ್ವಜನಿಕ ಶ್ರೇಣಿಯ ಬದಲು ನೀವು ನಿಜವಾಗಿ ತಲುಪುತ್ತಿರುವ ಸೇವೆಯಿಂದ ತೆಗೆದ ಗಮ್ಯಸ್ಥಾನದ ನಿಜವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಬಳಸಿ. ಎಲ್ಲಾ ನಿರ್ಗಮನವನ್ನು ಸರಿಸುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಪರಿಗಣಿಸುವ ಮೊದಲು ಒಂದು ಅನುಮೋದಿತ ಸೇವೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನಂತರ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಕೆಲಸದ ಒತ್ತಡದ ಸಬ್‌ನೆಟ್‌ಗೆ ಲಗತ್ತಿಸಿ. ಗೇಟ್‌ವೇ ಸಬ್‌ನೆಟ್‌ಗೆ ತನ್ನದೇ ಆದ ಅಗತ್ಯಗಳಿವೆ, ಮತ್ತು ನಿಮ್ಮ ಕೋಷ್ಟಕವನ್ನು ಅಲ್ಲಿ ಲಗತ್ತಿಸುವುದು ಒತ್ತಡವನ್ನು ನಿರ್ದೇಶಿಸುವ ಬದಲು ಗೇಟ್‌ವೇಯನ್ನು ಮುರಿಯುತ್ತದೆ.

ಮಾರ್ಗವನ್ನು ರಚಿಸಿ, ನಂತರ ಕೋಷ್ಟಕವನ್ನು ಒತ್ತಡವನ್ನು ಹೊಂದಿರುವ ಸಬ್‌ನೆಟ್‌ಗೆ ಬಂಧಿಸಿ:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

ಪ್ರಸಾರವೂ ಮುಖ್ಯ. ಆ ಕೋಷ್ಟಕದಲ್ಲಿ BGP ಪ್ರಸಾರ ಸಕ್ರಿಯವಾಗಿದ್ದರೆ, ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ನೀವು ಬರೆದವುಗಳ ಜೊತೆಗೆ ಕಾಣಿಸುತ್ತವೆ, ಮತ್ತು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್ ವಿಶಾಲ UDR ಅನ್ನು ಸೋಲಿಸಬಹುದು. ಪ್ರಸಾರವನ್ನು ನೀವು ಆ ಸಬ್‌ನೆಟ್‌ಗೆ UDR ಸಮೂಹವು ಅಧಿಕೃತವಾಗಿರಬೇಕೆಂದು ಬಯಸಿದಾಗ ಮಾತ್ರ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ.

ಆನ್-ಪ್ರಿಮೈಸ್ ಅರ್ಧವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಹರಿವು ಅಲ್ಲೇ ಸಾಯುತ್ತದೆ

ಆನ್-ಪ್ರಿಮೈಸ್ ಗೇಟ್‌ವೇ Azure ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಅದನ್ನು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ರವಾನಿಸಬೇಕು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅನುಮತಿ ನೀಡಬೇಕು. ಅದರ ಮುಂದಿನ ಮಾರ್ಗವು ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನ ಅಥವಾ ಇನ್ನೊಂದು ಖಾಸಗಿ ಹಾಪ್ ಆಗಿರಬಹುದು, ಆದರೆ ಆ ನಿರ್ಧಾರ ಯೋಜನೆಯಲ್ಲಿದೆ, Azure ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಲ್ಲ. ಸಾಮಾನ್ಯ ವೈಫಲ್ಯ ಹಿಂತಿರುಗುವಿಕೆ. ಇಂಟರ್ನೆಟ್ ಗಮ್ಯಸ್ಥಾನವು ಖಾಸಗಿ Azure ಮೂಲವನ್ನು ನಿಮ್ಮ ಕಡೆಗೆ ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಉತ್ತರವು ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇಗೆ ಹೋಗಿ ಸಾಯುತ್ತದೆ, ಅಥವಾ ಹೊರಹೋಗುವುದೇ ಇಲ್ಲ.

ಎರಡು ವಿನ್ಯಾಸಗಳು ಇದನ್ನು ಪರಿಹರಿಸುತ್ತವೆ ಮತ್ತು ಅವು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದವು. ನಿರ್ಗಮನದಲ್ಲಿ ಮೂಲವನ್ನು ಭಾಷಾಂತರಿಸಿ, ಇದರಿಂದ ಗಮ್ಯಸ್ಥಾನವು ಆನ್-ಪ್ರಿಮೈಸ್ ನೆಟ್‌ವರ್ಕ್ ಹೊಂದಿರುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ಅಥವಾ ಮೂಲವನ್ನು ಉಳಿಸಿ ಮತ್ತು ಉತ್ತರಗಳು ಸುರಂಗದ ಮೂಲಕ ಹಿಂತಿರುಗುವಂತೆ ರೂಟ್ ಮಾಡಿದ ಹಿಂತಿರುಗುವ ಸಂಬಂಧವನ್ನು ನಿರ್ಮಿಸಿ. ಒಂದನ್ನು ಆರಿಸಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಯಾವ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ.

ಸೆಲೆಕ್ಟರ್‌ಗಳು ಮತ್ತು ಅನುಮತಿ ಪಟ್ಟಿಗಳು ಇವೆಲ್ಲದರಿಂದ ಪ್ರತ್ಯೇಕ. Azure ಮುಂದಿನ ಹಾಪ್ ಆಯ್ಕೆ ಮಾಡುವುದು VPN ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಬಾಹ್ಯ ಸೇವೆಯ ಮೂಲ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಗಮ್ಯಸ್ಥಾನ ನೋಡುವ ಮೂಲದೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ

ವಿನಂತಿಯನ್ನು ಇನ್ನೊಂದು ಸಬ್‌ನೆಟ್‌ನ ಜಂಪ್ ಹೋಸ್ಟ್‌ನಿಂದ ಅಲ್ಲ, ನಿಜವಾದ ಕೆಲಸದ ಒತ್ತಡದಿಂದ ಕಳುಹಿಸಿ, ನಂತರ ಗಮ್ಯಸ್ಥಾನ ನೋಡಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ಓದಿ. ಆ ಒಂದೇ ಮೌಲ್ಯವು ಎರಡು ಹಿಂತಿರುಗುವ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದು ಜಾರಿಯಲ್ಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ನಂತರ ಉತ್ತರ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು VM ಗೆ ಸಾಮಾನ್ಯ ನಿರ್ವಹಣಾ ಸಂಚಾರವು ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಆಕಸ್ಮಿಕವಾಗಿ ಸೇರಿಸಿದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ಮುರಿದ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿ ಕಾಣುವುದಕ್ಕಿಂತ ಬಹಳ ಮೊದಲೇ ಮುರಿದ SSH ಅಧಿವೇಶನವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಆಯ್ದ ಪ್ರಿಫಿಕ್ಸ್ ಮೂಲಕ ಸಾಗಣೆ ಬಲವಂತದ ಸುರಂಗೀಕರಣಕ್ಕಿಂತ ತುಂಬಾ ಸಣ್ಣ ಬದಲಾವಣೆ. ಅದನ್ನು ಸಣ್ಣದಾಗಿ ಇರಿಸಿ ಮತ್ತು ಹಿಂತಿರುಗಿಸುವುದು ಒಂದು ಮಾರ್ಗವನ್ನು ಅಳಿಸುವುದು.