VPN ಮೇಲೆ Azure ಖಾಸಗಿ DNS: ರಿಝಾಲ್ವರ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಫಾರ್ವರ್ಡರ್
ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಸುರಂಗದ ಮೂಲಕ ಖಾಸಗಿ ವಲಯಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ನಿರ್ವಹಿತ ಒಳಬರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಫಾರ್ವರ್ಡರ್ VM ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ನಂತರ ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇರಬೇಕಾದ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಆನ್-ಪ್ರೆಮಿಸ್ನ ಸರ್ವರ್ ಖಾಸಗಿ ವಿಳಾಸದ ಮೂಲಕ Azure VM ತಲುಪುತ್ತದೆ ಮತ್ತು ಅದರ ಖಾಸಗಿ ಹೋಸ್ಟ್ನಾಮ್ ಅನ್ನು ಇನ್ನೂ ಪರಿಹರಿಸಲಾಗದು, ಇದು ಜನರನ್ನು ಮುರಿದ ಸುರಂಗ ಹುಡುಕಲು ಕಳುಹಿಸುತ್ತದೆ. ಸುರಂಗ ಸರಿಯಾಗಿದೆ. ಕಾಣೆಯಾದದ್ದು DNS ಗಡಿ: ಆನ್-ಪ್ರೆಮಿಸ್ ಬದಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ Azure ಖಾಸಗಿ ವಲಯಕ್ಕೆ VNet ಒಳಗಿನ ರಿಝಾಲ್ವರ್ ಉತ್ತರಿಸಬೇಕೆಂದು ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಎರಡು ವಿನ್ಯಾಸಗಳು ಈ ಕಂದಕವನ್ನು ಮುಚ್ಚುತ್ತವೆ, ಮತ್ತು ಅವು ನೀವು ಕೊನೆಗೆ ಏನನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಿ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ, ಪ್ರಶ್ನೆಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆಯೇ ಎಂಬುದರಲ್ಲಿ ಅಲ್ಲ.
ಸುರಂಗ ಪ್ರಶ್ನೆಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ವಲಯ ಜ್ಞಾನವನ್ನಲ್ಲ
ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕವು ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಎರಡು ನೆಟ್ವರ್ಕ್ಗಳ ನಡುವೆ ಮಾರ್ಗ ನೀಡುತ್ತದೆ. ಅದು ಆನ್-ಪ್ರೆಮಿಸ್ DNS ಸರ್ವರ್ಗೆ ಯಾವ ನಾಮಾವಕಾಶ Azure ಗೆ ಸೇರಿದೆ ಅಥವಾ ಯಾವ ವಿಳಾಸ ಉತ್ತರಿಸಬೇಕು ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರಶ್ನೆ ಒಂದೋ ಇಂಟರ್ನೆಟ್ಗೆ ಹೋಗಿ ಖಾಲಿಯಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆ, ಅಥವಾ ಸ್ಥಳೀಯ ರಿಝಾಲ್ವರ್ನಿಂದ ಎಂದಿಗೂ ಹೊರಡುವುದಿಲ್ಲ.
ಪರಿಹಾರವು ಸುಲಭವಾಗಿ ಬೇರ್ಪಡಿಸಬಹುದಾದ ಎರಡು ಅರ್ಧಗಳನ್ನು ಹೊಂದಿದೆ. ಒಂದು ಅರ್ಧ ಸುರಂಗದ ಮೂಲಕ ಬರುವ ಪ್ರಶ್ನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವ VNet ಒಳಗಿನ ರಿಝಾಲ್ವರ್. ಇನ್ನೊಂದು ಅರ್ಧ ಆನ್-ಪ್ರೆಮಿಸ್ ಬದಿಯಲ್ಲಿರುವ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್, ಅದು ನಿಖರವಾಗಿ ಒಂದು ನಾಮಾವಕಾಶವನ್ನು ಆ ರಿಝಾಲ್ವರ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಯಾವುದೇ ಅರ್ಧ ಒಂಟಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ಈ ವಿವರಣೆಯ ಉಳಿದ ಭಾಗಕ್ಕೆ ವಲಯ cloud.corp.example ಎಂದು ಊಹಿಸಿ, ಮತ್ತು ಪ್ರತಿ ವಿಳಾಸವನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಪರಿಗಣಿಸಿ.
ಆಯ್ಕೆ A: ನಿರ್ವಹಿತ ಒಳಬರುವ ಎಂಡ್ಪಾಯಿಂಟ್
Azure DNS Private Resolver VNet ನ ಹೊರಗಿನಿಂದ DNS ಪ್ರಶ್ನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಒಳಬರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಒದಗಿಸುತ್ತದೆ. ನೀವು ಅದನ್ನು ಮೀಸಲಾದ ನಿಯೋಜಿತ ಸಬ್ನೆಟ್ನಲ್ಲಿ ನಿಯೋಜಿಸುತ್ತೀರಿ, ಖಾಸಗಿ ವಲಯವನ್ನು ಆ VNet ಗೆ ಲಿಂಕ್ ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಸೇವೆ ನೀಡುವ ಒಳಬರುವ ವಿಳಾಸವನ್ನು ಗಮನಿಸುತ್ತೀರಿ.
ನಂತರ ಆನ್-ಪ್ರೆಮಿಸ್ DNS ಸರ್ವರ್ನಲ್ಲಿ ನಿಖರ ನಾಮಾವಕಾಶಕ್ಕಾಗಿ ಆ ವಿಳಾಸದ ಕಡೆಗೆ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ ರಚಿಸುತ್ತೀರಿ:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft ನ ಹೈಬ್ರಿಡ್ DNS ಕಾರ್ಯವಿಧಾನ ವಲಯ ಲಿಂಕ್ ಮತ್ತು ಫಾರ್ವರ್ಡರ್ ಹಂತ ಎರಡನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ. ನಿರ್ವಹಿತ ಮಾರ್ಗವು ಪ್ಯಾಚ್ ಮಾಡಲು DNS ಸಾಫ್ಟ್ವೇರ್ ಬಿಡುವುದಿಲ್ಲ, ಮತ್ತು ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸವು ಸಂಪನ್ಮೂಲದ ಜೀವಿತಾವಧಿಯುದ್ದಕ್ಕೂ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
ಬೆಲೆ ಎಂದರೆ ಈಗ ನಿಮ್ಮ ಬಳಿ ರಿಝಾಲ್ವರ್ ಸಂಪನ್ಮೂಲ, ಅದರ ಸಬ್ನೆಟ್ ನಿಯೋಜನೆ ಮತ್ತು ಅದರ ವೆಚ್ಚ ಇದೆ, ಇದು ಪ್ರಶ್ನೆಗಳ ಪ್ರಮಾಣ ತುಂಬಾ ಕಡಿಮೆಯಿದ್ದರೂ ನಿಜವಾಗಿದೆ.
ಆಯ್ಕೆ B: VNet ಒಳಗೆ ಫಾರ್ವರ್ಡರ್ VM
ಹಳೆಯ ವಿನ್ಯಾಸವು VNet ನಲ್ಲಿನ ಸಾಮಾನ್ಯ VM ನಲ್ಲಿ DNS ಸಾಫ್ಟ್ವೇರ್ ಚಲಾಯಿಸುತ್ತದೆ: Windows DNS, BIND ಅಥವಾ dnsmasq, ಮತ್ತು ಖಾಸಗಿ ವಲಯವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಹೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ ಅಥವಾ 168.63.129.16 ನಲ್ಲಿನ Azure ರಿಝಾಲ್ವರ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಆನ್-ಪ್ರೆಮಿಸ್ ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ ಆ VM ನ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತದೆ.
ಈ ಆಯ್ಕೆ ಈಗಾಗಲೇ DNS ಸರ್ವರ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ತಂಡಗಳಿಗೆ ಪರಿಚಿತವಾಗಿದೆ, ಮತ್ತು ಇದು ಲಾಗಿಂಗ್ ಅಥವಾ ಸ್ಪ್ಲಿಟ್-ಹೊರೈಜನ್ ಉತ್ತರಗಳಂತಹ ಹೆಚ್ಚುವರಿ ತರ್ಕವನ್ನು ಹೊತ್ತೊಯ್ಯಬಹುದು. ಇದು DNS ಸರ್ವರ್ನ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣಾ ಕರ್ತವ್ಯವನ್ನೂ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ: ಪ್ಯಾಚಿಂಗ್, ಲಭ್ಯತೆಗಾಗಿ ಎರಡನೇ ಇನ್ಸ್ಟಾನ್ಸ್, ಮೇಲ್ವಿಚಾರಣೆ, ಮತ್ತು VM ಬದಲಾದಾಗ ಹಾಗೂ ಅದರ ವಿಳಾಸ ಬದಲಾದಾಗ ಮರುನಿರ್ಮಾಣದ ಮಾರ್ಗ.
ಸಾಮಾನ್ಯ VNet ಹೋಸ್ಟ್ DNS ಪ್ರಾಕ್ಸಿ ಅಲ್ಲ, ಸೇವೆ ಸ್ಥಾಪಿತವಾಗಿ ಆ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಉತ್ತರಿಸಲು ಅನುಮತಿ ಸಿಗುವವರೆಗೆ, ಮತ್ತು VM ಕ್ಲೋನ್ ಮಾಡುವಾಗ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಹಂತ ಅದೇ.
ಯಾವುದು ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣೆಗೆ ಸರಿಹೊಂದುತ್ತದೆ
ಹೋಲಿಕೆ ಯಾವ ವಿನ್ಯಾಸ ವೇಗವಾಗಿದೆ ಎಂಬುದಲ್ಲ. ಅದು ನೀವು DNS ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತೀರಾ ಎಂಬುದು, ಮತ್ತು ಪ್ರಶ್ನೆಗಳ ಪ್ರಮಾಣವು ಎಂಡ್ಪಾಯಿಂಟ್ ಹಾಗೂ ಪ್ರಶ್ನೆಗೆ ಅನುಸಾರ ಬಿಲ್ ಮಾಡುವ ನಿರ್ವಹಿತ ಸಂಪನ್ಮೂಲವನ್ನು ಸಮರ್ಥಿಸುತ್ತದೆಯೇ ಎಂಬುದು.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
ಯಾವ ಸಾಲು ನಿರ್ಧರಿಸಿದರೂ, ಆನ್-ಪ್ರೆಮಿಸ್ ಫಾರ್ವರ್ಡರ್ ನಿಯಮ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ. ಇದೇ ಭಾಗ ಎರಡೂ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಇರಬೇಕು, ಮತ್ತು Azure ಒಳಗಿನಿಂದ ಪರಿಹಾರ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಕಚೇರಿಯಿಂದ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಯಾರಾದರೂ ವರದಿ ಮಾಡಿದಾಗ ಹೆಚ್ಚಾಗಿ ಕಾಣೆಯಾಗುವ ಭಾಗ ಇದೇ.
ಮಾರ್ಗವನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ
ವಲಯವು ರಿಝಾಲ್ವರ್ ಹೊಂದಿರುವ VNet ಗೆ ಲಿಂಕ್ ಆಗಿದೆ ಎಂದು ಮತ್ತು ಆನ್-ಪ್ರೆಮಿಸ್ ಫಾರ್ವರ್ಡರ್ ಪೋಷಕ ಡೊಮೇನ್ ಅಲ್ಲ, ನಾಮಾವಕಾಶವನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. corp.example ಗಾಗಿ ಫಾರ್ವರ್ಡರ್, ರಿಝಾಲ್ವರ್ ಸ್ವತಃ ನಿಯೋಜಿಸದಿದ್ದರೆ cloud.corp.example ಗೆ ಹೊಂದುವುದಿಲ್ಲ, ಮತ್ತು ಈ ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆ ಕಾಣೆಯಾದ ದಾಖಲೆಯಂತೆ ಕಾಣುವ ಸ್ವಚ್ಛ ಋಣಾತ್ಮಕ ಉತ್ತರವನ್ನು ನೀಡುತ್ತದೆ.
ನಂತರ ಪ್ರಶ್ನೆ ಎಂಡ್ಪಾಯಿಂಟ್ ತಲುಪುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ: ಆನ್-ಪ್ರೆಮಿಸ್ ಮೂಲಕ್ಕೆ ರಿಝಾಲ್ವರ್ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ UDP ಮತ್ತು TCP ಎರಡರಲ್ಲೂ ಪೋರ್ಟ್ 53 ತೆರೆದಿರಬೇಕು. NSG ಕಾಣೆಯಾದ ವಲಯ ದಾಖಲೆಯನ್ನು ಒದಗಿಸಲಾರದು, ಮತ್ತು ಸರಿಯಾದ ವಲಯವು ಎಂದಿಗೂ ಬಾರದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲಾರದು.
ರೋಗನಿರ್ಣಯ ಮಾಡುವಾಗ ಕೇಳಿದ FQDN ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ರಿಝಾಲ್ವರ್ನ ಪಕ್ಕದಲ್ಲಿಡಿ, ಮತ್ತು ಟೈಮೌಟ್ ಅನ್ನು ಋಣಾತ್ಮಕ ಉತ್ತರದಿಂದ ಬೇರ್ಪಡಿಸಿ. ಟೈಮೌಟ್ ಮಾರ್ಗ ಅಥವಾ ನೀತಿಯ ಸಮಸ್ಯೆ. ಋಣಾತ್ಮಕ ಉತ್ತರ ಎಂದರೆ ಪ್ರಶ್ನೆ ಬಂದಿತು ಮತ್ತು ನಾಮಾವಕಾಶ ಹೊಂದಲಿಲ್ಲ. ಕೆಲಸದ ಕ್ರಮ: ವಲಯವನ್ನು ಲಿಂಕ್ ಮಾಡಿ, ಷರತ್ತುಬದ್ಧ ಫಾರ್ವರ್ಡರ್ ಸೇರಿಸಿ, ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪೋರ್ಟ್ 53 ತೆರೆಯಿರಿ, ಆನ್-ಪ್ರೆಮಿಸ್ನಿಂದ ಒಂದು ಹೆಸರನ್ನು ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ನಂತರವೇ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಅಧಿಕಾರವನ್ನು ನೋಡಿ.