resolver ಪಿಯರ್ಡ್ VNet ನಲ್ಲಿದ್ದಾಗ Azure P2S DNS ವಿಫಲವಾಗುತ್ತದೆ

VM ಗೆ ಪಿಂಗ್ ಮಾಡಿ ಮತ್ತು ಅದು ಉತ್ತರಿಸುತ್ತದೆ; ಅದರ ಹೆಸರನ್ನು ಕೇಳಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್ ಅಜ್ಞಾತ ಎಂದು ಹೇಳುತ್ತದೆ. resolver VPN ಗೇಟ್‌ವೇ ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲದೆ ಪಿಯರ್ಡ್ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿದ್ದಾಗ, ಫಲಿತಾಂಶಗಳ ಈ ಜೋಡಿ ನಿರೀಕ್ಷಿತವಾಗಿದೆ, ಮತ್ತು resolver ದೋಷನಿವಾರಣೆಯ ಯಾವುದೇ ಪ್ರಮಾಣವೂ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಕಾಣೆಯಾದದ್ದು ಪಿಯರಿಂಗ್ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ರೂಟಿಂಗ್ ಒಪ್ಪಂದ. ಎರಡು ಟೋಪಾಲಜಿಗಳು ಕಾಗದದ ಮೇಲೆ ಬಹುತೇಕ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಮುರಿದಿರುವ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಇರಿಸಲಾದ ಪಿಯರಿಂಗ್ ಸ್ವಿಚ್‌ಗಳ ಜೋಡಿ.

ಒಂದು ಲ್ಯಾಪ್‌ಟಾಪ್ VNet2 ನಲ್ಲಿನ ಗೇಟ್‌ವೇಗೆ ಟನೆಲ್ ಮಾಡುತ್ತಿದೆ, DNS ಸೇವೆ ನೀಡುವ ಡೊಮೇನ್ ನಿಯಂತ್ರಕ VNet1 ನಲ್ಲಿ ಕುಳಿತಿದೆ ಎಂದು ಊಹಿಸಿ.

ಎರಡು ಟೋಪಾಲಜಿ, ಒಂದು ವ್ಯತ್ಯಾಸ

resolver ಅನ್ನು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನೊಳಗೆ ಇರಿಸಿ ಮತ್ತು ಟನೆಲ್ ಮೇಲೆ ಬಂದ ಕ್ಷಣ ಹೆಸರು ಪರಿಹಾರವಾಗುತ್ತದೆ. ಆ ಹುಡುಕಾಟದಲ್ಲಿ ಯಾವುದೇ ಪಿಯರಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ ಭಾಗವಹಿಸುವುದಿಲ್ಲ.

ಅದೇ resolver ಅನ್ನು ಪಿಯರಿಂಗ್‌ನ ಆಚೆಗೆ ಸರಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ VM ನಿಂದ ಉತ್ತರ ಪಡೆಯುತ್ತದೆ ಆದರೆ ಹೆಸರು ಅಜ್ಞಾತವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ, ಟನೆಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಲಾಗಿಲ್ಲ. ಸರಿದದ್ದು ಒಂದೇ ಒಂದು ವಿಷಯ - resolver ಎಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಎಂಬುದು. ಪಿಯರಿಂಗ್ ಅದಕ್ಕೆ ಆ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವನ್ನು ನೀಡಿತು, ಗೇಟ್‌ವೇಗೆ ಅಲ್ಲಿಗೆ ಸಂಚಾರ ಸಾಗಿಸುವ ಅಧಿಕಾರವನ್ನಲ್ಲ.

ಬದಿ A: ಗೇಟ್‌ವೇ ಮಾಲೀಕರ ಮೇಲೆ ಗೇಟ್‌ವೇ ಟ್ರಾನ್ಸಿಟ್ ಅನ್ನು ಅನುಮತಿಸಿ

ಪಿಯರಿಂಗ್ ಎರಡು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದರೆ ಈ ಸೇರಿಕೆ ಗೇಟ್‌ವೇ ಮೂಲಕ ಬರುವ ಸಂಚಾರಕ್ಕೆ ಪರಿವರ್ತಕವಲ್ಲ, ಮತ್ತು ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ವಿನಂತಿ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಬರುತ್ತದೆ. ಆದ್ದರಿಂದ VNet2 ನಲ್ಲಿನ ಗೇಟ್‌ವೇ ವಿನ್ಯಾಸ ಅನುಮತಿಸುವವರೆಗೆ ಹುಡುಕಾಟವನ್ನು VNet1 ಗೆ ಒಪ್ಪಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿಲ್ಲ. ಅನುಮತಿ ಎಂಬುದು ಗೇಟ್‌ವೇ ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್‌ನ ಮಾಲೀಕತ್ವದ ಪಿಯರಿಂಗ್‌ನಲ್ಲಿರುವ ಸ್ವಿಚ್.

VNet2 ರಿಂದ VNet1 ಕಡೆಗಿನ ಪಿಯರಿಂಗ್‌ನಲ್ಲಿ Allow gateway transit ಸೆಟ್ ಮಾಡಿ. ಈ ಗುಣಲಕ್ಷಣ ಗೇಟ್‌ವೇ ಸಂಪನ್ಮೂಲದ್ದಲ್ಲ, ಪಿಯರಿಂಗ್ ಆಬ್ಜೆಕ್ಟ್‌ನದು, ಆದ್ದರಿಂದ ಅದನ್ನು ಪಿಯರಿಂಗ್ ಬ್ಲೇಡ್‌ನಲ್ಲಿ ಓದಿ ಬದಲಿಸುತ್ತೀರಿ. ಬದಿ A ಸಂಪೂರ್ಣವಾಗಿ ಇಷ್ಟೇ.

ಬದಿ B: ಪಿಯರ್‌ನಲ್ಲಿ ರಿಮೋಟ್ ಗೇಟ್‌ವೇಗಳನ್ನು ಬಳಸಿ

ಇನ್ನೊಂದು ಅರ್ಧವು ಕನ್ನಡಿ ಪ್ರತಿಬಿಂಬ: VNet1 ರಿಂದ VNet2 ಗೆ ಹಿಂತಿರುಗುವ ಪಿಯರಿಂಗ್‌ನಲ್ಲಿ Use remote gateways ಸಕ್ರಿಯಗೊಳಿಸಿ. ಅದೇ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ, ಅಥವಾ ಒಂದೇ ತುದಿಯಲ್ಲಿ ಆನ್ ಮಾಡಿದರೆ ಅರ್ಧ ನಿರ್ಮಿತ ಮಾರ್ಗ ಮತ್ತು ಮೂಲ ಲಕ್ಷಣ ಅಸ್ಪೃಶವಾಗಿ ಉಳಿಯುತ್ತದೆ. VPN ಗೇಟ್‌ವೇ ಇರುವ ನೆಟ್‌ವರ್ಕ್ ಮಾತ್ರ ಟ್ರಾನ್ಸಿಟ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಪಿಯರ್ ಅದನ್ನು ಬಳಸುವ ಬದಿ.

ಕೊನೆಯದಾಗಿ ತೆರೆದ ಪೋರ್ಟಲ್ ಬ್ಲೇಡ್ ಅನ್ನು ನಂಬುವ ಬದಲು ಎರಡೂ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಎರಡೂ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಓದಿ.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

ಜೋಡಿಯನ್ನು ಅಕ್ಕಪಕ್ಕ ನೋಡುವುದು ತಲೆಕೆಳಗಾದ ಸೆಟ್ಟಿಂಗ್ ಹಿಡಿಯುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ. ಗೇಟ್‌ವೇ ಬದಿಯಲ್ಲಿ AllowGatewayTransit false ಎಂದು ವರದಿ ಮಾಡುವ ಪಿಯರಿಂಗ್ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯದೆಯೇ ಇಡೀ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಏನನ್ನು ಪಡೆಯಬೇಕು

ರೂಟಿಂಗ್ ಅಗತ್ಯ ಮತ್ತು ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಪ್ರೊಫೈಲ್ ಟ್ರಾನ್ಸಿಟ್ ಕೆಲಸ ಮಾಡಿದ ನಂತರ ಉತ್ತರಿಸುವ DNS ವಿಳಾಸವನ್ನೂ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಬೇಕು. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ resolver ಆ ವಿಳಾಸವಲ್ಲ: ಅದು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಲಿಂಕ್ ಆದ Azure Private DNS ವಲಯಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಡೈರೆಕ್ಟರಿ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಆದ ವಲಯಕ್ಕೆ ಏನೂ ಇಲ್ಲ, ಮತ್ತು ಈ ನಿಯೋಜನೆ ಅದನ್ನೇ ಬಳಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಅನ್ನು ಅದಕ್ಕೆ ತೋರಿಸಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಸಂತೋಷದಿಂದ ಪರಿಹಾರವಾಗುತ್ತವೆ ಆದರೆ ಒಳಗಿನ ಹೋಸ್ಟ್ ಅಜ್ಞಾತವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಬೇರೆ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಸಂಪರ್ಕಿತ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ resolver ಅನ್ನು ಕೇಳಿ.

nslookup dc01.corp.example 10.1.0.4

ಸಮಯ ಮೀರಿಕೆ ಮಾರ್ಗ ಇನ್ನೂ ಇಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಅಧಿಕೃತ ಉತ್ತರ ಸಮಸ್ಯೆಯನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ತಳ್ಳುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಎಂದೂ ಸೇರಿಸದ ಪ್ರತ್ಯಯ, ಆದ್ದರಿಂದ ಸಣ್ಣ ಹೆಸರುಗಳು ಅವನ್ನು ಸಂತೋಷದಿಂದ ವಿಫಲಗೊಳಿಸುವ ಸಾರ್ವಜನಿಕ resolver ಗೆ ಪ್ರಯಾಣಿಸುತ್ತವೆ.

ಸೈಟ್-ಟು-ಸೈಟ್ ಬದಿಯಲ್ಲಿ ಅದೇ ಒಪ್ಪಂದವನ್ನು ಹೋಲಿಸಿ

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ವಿಶೇಷವಾಗಿ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳಿಗೆ ಸೇರಿದ್ದಲ್ಲ. ಕ್ಲೈಂಟ್ ಬದಲು ಸೈಟ್-ಟು-ಸೈಟ್‌ನ ಶಾಖೆಯನ್ನು ಇರಿಸಿ ಮತ್ತು ಎರಡು ಬದಿಯ ಷರತ್ತು ಮರಳುತ್ತದೆ: ಶಾಖೆ ನೇರವಾಗಿ ಗೇಟ್‌ವೇ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬರುತ್ತದೆ, ಮತ್ತು ಎರಡು ನೆಟ್‌ವರ್ಕ್ ದೂರದ ಸೇವೆ ಇನ್ನೂ ಪಿಯರಿಂಗ್‌ನ ಹಿಂದೆ ಇದೆ.

ಟ್ರಾನ್ಸಿಟ್ ಅನ್ನು ಎರಡೂ ಪಿಯರಿಂಗ್‌ಗಳಲ್ಲಿ ನೀಡಬೇಕು, ಮತ್ತು ಅದನ್ನು ನೀಡುವ ಸ್ವಿಚ್ ಕ್ಲೈಂಟ್ ಪ್ರಕಾರದಲ್ಲ, ಪಿಯರಿಂಗ್‌ನಲ್ಲಿದೆ.

ಗೇಟ್‌ವೇಗೆ ದೋಷ ಹೊರಿಸುವ ಮೊದಲು

Windows ಪ್ರತಿ ಅಡಾಪ್ಟರ್‌ಗೆ resolver ಪಟ್ಟಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಗೇಟ್‌ವೇಗೆ ದೋಷ ಹೊರಿಸುವ ಮೊದಲು ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ನಿಜವಾಗಿ ಏನನ್ನು ಪಡೆಯಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

ಋಣಾತ್ಮಕ ಉತ್ತರ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ರೂಟಿಂಗ್ ತಿದ್ದುಪಡಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ ಪ್ರತ್ಯಯ ಪಟ್ಟಿ ವಲಯ ಎಂದೂ ಹೋಸ್ಟ್ ಆಗದ ಸ್ಥಳಕ್ಕೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಫ್ಲಶ್ ಮಾಡಿ, ಮತ್ತೆ ಕೇಳಿ, ಮತ್ತು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ.

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