Ιδιωτικό DNS του Azure μέσω VPN: τελικό σημείο resolver ή forwarder
Και τα δύο σχέδια απαντούν σε ιδιωτικές ζώνες μέσω της σήραγγας. Συγκρίνετε ένα διαχειριζόμενο εισερχόμενο τελικό σημείο με μια εικονική μηχανή forwarder και μετά ελέγξτε τη διαδρομή που πρέπει να υπάρχει σε κάθε περίπτωση.
Ένας διακομιστής στην τοπική εγκατάσταση φτάνει σε μια εικονική μηχανή Azure μέσω ιδιωτικής διεύθυνσης και παρόλα αυτά δεν μπορεί να επιλύσει το ιδιωτικό της όνομα κεντρικού υπολογιστή, κάτι που οδηγεί τους ανθρώπους να ψάχνουν για χαλασμένη σήραγγα. Η σήραγγα είναι εντάξει. Αυτό που λείπει είναι ένα όριο DNS: τίποτα στην τοπική πλευρά δεν γνωρίζει ότι μια συγκεκριμένη ιδιωτική ζώνη του Azure πρέπει να απαντιέται από έναν resolver μέσα στο VNet. Δύο σχέδια κλείνουν αυτό το κενό και διαφέρουν σε αυτό που τελικά διαχειρίζεστε, όχι στο αν λειτουργούν τα ερωτήματα.
Η σήραγγα μεταφέρει ερωτήματα, όχι γνώση ζωνών
Μια σύνδεση site-to-site δίνει στα πακέτα μια διαδρομή μεταξύ των δύο δικτύων. Δεν λέει στον τοπικό διακομιστή DNS ποιος χώρος ονομάτων ανήκει στο Azure ή ποια διεύθυνση πρέπει να απαντήσει, οπότε το ερώτημα είτε πηγαίνει στο διαδίκτυο και επιστρέφει κενό είτε δεν φεύγει ποτέ από τον τοπικό resolver.
Η διόρθωση έχει δύο μισά που χωρίζονται εύκολα. Το ένα μισό είναι ένας resolver μέσα στο VNet που δέχεται ερωτήματα που φτάνουν μέσω της σήραγγας. Το άλλο είναι ένας υπό όρους forwarder στην τοπική πλευρά που στέλνει ακριβώς έναν χώρο ονομάτων σε αυτόν τον resolver. Κανένα μισό δεν λειτουργεί μόνο του.
Υποθέστε ότι η ζώνη είναι cloud.corp.example για την υπόλοιπη περιήγηση και θεωρήστε κάθε διεύθυνση ενδεικτική.
Επιλογή A: το διαχειριζόμενο εισερχόμενο τελικό σημείο
Το Azure DNS Private Resolver παρέχει ένα εισερχόμενο τελικό σημείο που δέχεται ερωτήματα DNS από έξω από το VNet. Το αναπτύσσετε σε ένα αποκλειστικό εκχωρημένο υποδίκτυο, συνδέετε την ιδιωτική ζώνη με αυτό το VNet και σημειώνετε την εισερχόμενη διεύθυνση που εκχωρεί η υπηρεσία.
Στον τοπικό διακομιστή DNS δημιουργείτε στη συνέχεια έναν υπό όρους forwarder για τον ακριβή χώρο ονομάτων προς αυτή τη διεύθυνση:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Η διαδικασία υβριδικού DNS της Microsoft τεκμηριώνει τόσο τη σύνδεση της ζώνης όσο και το βήμα του forwarder. Η διαχειριζόμενη διαδρομή δεν σας αφήνει λογισμικό DNS για ενημερώσεις και η διεύθυνση του τελικού σημείου μένει σταθερή για όλη τη ζωή του πόρου.
Το τίμημα είναι ότι πλέον έχετε έναν πόρο resolver, την εκχώρηση υποδικτύου του και το κόστος του, που είναι πραγματικό ακόμη και όταν ο όγκος ερωτημάτων είναι ελάχιστος.
Επιλογή B: εικονική μηχανή forwarder μέσα στο VNet
Το παλαιότερο σχέδιο εκτελεί λογισμικό DNS σε μια συνηθισμένη εικονική μηχανή μέσα στο VNet: Windows DNS, BIND ή dnsmasq, με την ιδιωτική ζώνη είτε να φιλοξενείται τοπικά είτε να προωθείται στον resolver του Azure στη διεύθυνση 168.63.129.16. Ο τοπικός υπό όρους forwarder δείχνει στην ιδιωτική διεύθυνση αυτής της μηχανής.
Αυτή η επιλογή είναι γνώριμη σε ομάδες που ήδη διαχειρίζονται διακομιστές DNS και μπορεί να μεταφέρει πρόσθετη λογική όπως καταγραφή ή απαντήσεις split-horizon. Κληρονομεί επίσης κάθε λειτουργική υποχρέωση ενός διακομιστή DNS: ενημερώσεις, δεύτερο στιγμιότυπο για διαθεσιμότητα, παρακολούθηση και διαδρομή ανοικοδόμησης όταν η μηχανή αντικαθίσταται και αλλάζει διεύθυνση.
Ένας συνηθισμένος κεντρικός υπολογιστής VNet δεν είναι μεσολαβητής DNS μέχρι να εγκατασταθεί η υπηρεσία και να της επιτραπεί να απαντά σε αυτούς τους πελάτες, και αυτό είναι το βήμα που παραλείπουν οι άνθρωποι όταν κλωνοποιούν μια εικονική μηχανή.
Ποιο ταιριάζει στη λειτουργία σας
Η σύγκριση δεν αφορά το ποιο σχέδιο είναι ταχύτερο. Αφορά το αν θέλετε να διαχειρίζεστε καθόλου λογισμικό 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 |
Όποια γραμμή κι αν αποφασίσει, ο κανόνας του forwarder στην τοπική πλευρά μοιάζει ίδιος. Αυτό είναι το μέρος που πρέπει να υπάρχει και στα δύο σχέδια και είναι το μέρος που λείπει πιο συχνά όταν κάποιος αναφέρει ότι η επίλυση λειτουργεί από μέσα στο Azure αλλά όχι από το γραφείο.
Ελέγξτε τη διαδρομή με σειρά
Επιβεβαιώστε ότι η ζώνη είναι συνδεδεμένη με το VNet που φιλοξενεί τον resolver και ότι ο τοπικός forwarder ονομάζει τον χώρο ονομάτων και όχι έναν γονικό τομέα. Ένας forwarder για το corp.example δεν θα ταιριάξει με το cloud.corp.example εκτός αν ο ίδιος ο resolver εκχωρεί, και η αναντιστοιχία παράγει μια καθαρή αρνητική απάντηση που μοιάζει με εγγραφή που λείπει.
Στη συνέχεια ελέγξτε ότι το ερώτημα φτάνει στο τελικό σημείο: η τοπική πηγή χρειάζεται διαδρομή προς τη διεύθυνση του resolver και διαδρομή επιστροφής, και η θύρα 53 τόσο για UDP όσο και για TCP πρέπει να επιτρέπεται όπου το επιτρέπει η πολιτική. Ένα NSG δεν μπορεί να παράσχει μια εγγραφή ζώνης που λείπει και μια σωστή ζώνη δεν μπορεί να απαντήσει σε ερώτημα που δεν φτάνει ποτέ.
Κρατήστε το ζητούμενο FQDN δίπλα στον resolver που επιλέξατε όταν διαγιγνώσκετε και διαχωρίστε ένα timeout από μια αρνητική απάντηση. Το timeout είναι πρόβλημα διαδρομής ή πολιτικής. Η αρνητική απάντηση σημαίνει ότι το ερώτημα έφτασε και ο χώρος ονομάτων δεν ταίριαξε. Σειρά εργασίας: συνδέστε τη ζώνη, προσθέστε τον υπό όρους forwarder, ανοίξτε τη θύρα 53 και προς τις δύο κατευθύνσεις, δοκιμάστε ένα όνομα από την τοπική εγκατάσταση και μόνο τότε κοιτάξτε την εξουσιοδότηση της ίδιας της εφαρμογής.