Το DNS του Azure P2S αποτυγχάνει όταν ο resolver βρίσκεται σε peered VNet

Ένας client μπορεί να φτάσει το δικό του virtual network και να αποτύχει να επιλύσει ονόματα σε ένα peered δίκτυο. Το peering δεν είναι transit gateway μέχρι να το πουν και οι δύο πλευρές.

Κάντε ping στο VM και απαντά· ζητήστε το όνομά του και ο client λέει ότι ο host είναι άγνωστος. Όταν ο resolver βρίσκεται σε peered virtual network αντί σε εκείνο που φιλοξενεί το gateway VPN, αυτό το ζεύγος αποτελεσμάτων είναι αναμενόμενο και κανένα μέγεθος αντιμετώπισης προβλημάτων του resolver δεν το αλλάζει. Αυτό που λείπει είναι ένα συμβόλαιο δρομολόγησης που το peering κρατά από προεπιλογή. Δύο τοπολογίες μοιάζουν σχεδόν ίδιες στο χαρτί, και η διαφορά ανάμεσα σε λειτουργικό και χαλασμένο είναι ένα ζεύγος διακοπτών peering τοποθετημένων στη σωστή κατεύθυνση.

Φανταστείτε ένα laptop να κάνει tunnel σε ένα gateway στο VNet2, με τον domain controller που σερβίρει DNS να κάθεται στο VNet1.

Δύο τοπολογίες, μία διαφορά

Βάλτε τον resolver μέσα στο ίδιο το virtual network του gateway και το όνομα επιλύεται μόλις σηκωθεί το tunnel. Καμία ρύθμιση peering δεν συμμετέχει σε αυτή την αναζήτηση.

Μετακινήστε τον ίδιο resolver πέρα από ένα peering και ο client εξακολουθεί να παίρνει απάντηση από το VM ενώ το όνομα μένει άγνωστο. Πιστοποιητικό, tunnel και client είναι αμετάβλητα. Το μόνο που μετακινήθηκε είναι πού ζει ο resolver. Το peering του έδωσε διαδρομή προς αυτή τη διεύθυνση, όχι εξουσία στο gateway να μεταφέρει κίνηση εκεί.

Πλευρά A: επιτρέψτε το gateway transit στον ιδιοκτήτη του gateway

Ένα peering ενώνει δύο virtual networks, αλλά η ένωση δεν είναι μεταβατική για κίνηση που φτάνει μέσω gateway, και ένα αίτημα point-to-site φτάνει ακριβώς έτσι. Το gateway στο VNet2 επομένως δεν έχει υπόσταση να παραδώσει την αναζήτηση στο VNet1 έως ότου το σχέδιο το επιτρέψει. Η άδεια είναι ένας διακόπτης στο peering που ανήκει στο δίκτυο που κρατά το gateway.

Ορίστε Allow gateway transit στο peering του VNet2 προς το VNet1. Η ιδιότητα ανήκει στο αντικείμενο peering, όχι στον πόρο gateway, οπότε τη διαβάζετε και την αλλάζετε στη λεπίδα peering. Αυτή είναι όλη η πλευρά A.

Πλευρά B: χρησιμοποιήστε απομακρυσμένα gateways στον peer

Το άλλο μισό είναι η κατοπτρική εικόνα: στο peering του VNet1 πίσω προς το VNet2, ενεργοποιήστε Use remote gateways. Το άναμμα της ίδιας σημαίας και στα δύο άκρα, ή μόνο στο ένα, αφήνει μισοχτισμένη διαδρομή και το αρχικό σύμπτωμα ανέγγιχτο. Μόνο το δίκτυο με το gateway VPN επιτρέπει transit, και ο peer είναι η πλευρά που το χρησιμοποιεί.

Διαβάστε και τις δύο ιδιότητες και στα δύο δίκτυα αντί να εμπιστεύεστε τη λεπίδα πύλης που ανοίξατε τελευταία.

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

Το να δείτε το ζεύγος δίπλα-δίπλα είναι ο γρηγορότερος τρόπος να πιάσετε ανεστραμμένη ρύθμιση. Ένα peering που αναφέρει AllowGatewayTransit false στην πλευρά του gateway εξηγεί ολόκληρη την αποτυχία χωρίς σύλληψη πακέτων.

Τι πρέπει να λάβει ακόμη ο client

Η δρομολόγηση είναι απαραίτητη και όχι αρκετή, γιατί το προφίλ point-to-site πρέπει επίσης να δώσει στον client μια διεύθυνση DNS που απαντά όταν δουλέψει το transit. Ο resolver της πλατφόρμας δεν είναι αυτή η διεύθυνση: απαντά σε ζώνες Azure Private DNS συνδεδεμένες με το virtual network, αλλά τίποτα για ζώνη που φιλοξενείται στους δικούς σας διακομιστές καταλόγου, και αυτό χρησιμοποιεί αυτή η ανάπτυξη. Στρέψτε έναν client εκεί και τα δημόσια ονόματα επιλύονται χαρούμενα ενώ ο εσωτερικός host μένει άγνωστος.

Ρωτήστε τον resolver από το συνδεδεμένο laptop πριν αλλάξετε οτιδήποτε άλλο.

nslookup dc01.corp.example 10.1.0.4

Ένα timeout λέει ότι η διαδρομή ακόμη λείπει. Μια έγκυρη απάντηση σπρώχνει το πρόβλημα πίσω στον client, συνήθως ένα επίθημα που δεν προστίθεται ποτέ, οπότε τα σύντομα ονόματα ταξιδεύουν σε δημόσιο resolver που τα αποτυγχάνει χαρούμενα.

Συγκρίνετε το ίδιο συμβόλαιο στην πλευρά site-to-site

Τίποτα από αυτά δεν ανήκει ειδικά στα laptops. Αλλάξτε τον client με ένα υποκατάστημα σε site-to-site και η απαίτηση δύο πλευρών επιστρέφει: το υποκατάστημα φτάνει απευθείας στο δίκτυο του gateway, και μια υπηρεσία δύο δίκτυα μακριά είναι ακόμη πίσω από το peering.

Το transit πρέπει να παραχωρηθεί και στα δύο peerings, και ο διακόπτης που το παραχωρεί ζει στο peering και όχι στον τύπο client.

Πριν κατηγορήσετε το gateway

Τα Windows κρατούν λίστα resolver ανά προσαρμογέα, οπότε επιβεβαιώστε τι έλαβε πραγματικά η διεπαφή tunnel πριν κατηγορήσετε το gateway.

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

Μια αρνητική απάντηση επιβιώνει της διόρθωσης δρομολόγησης στην cache, και μια παρωχημένη λίστα επιθημάτων συνεχίζει να στέλνει ερωτήματα κάπου που ποτέ δεν φιλοξένησε τη ζώνη. Καθαρίστε, ρωτήστε ξανά και σημειώστε ποιος διακομιστής απαντά.

Δύο μικρότερες συνθήκες αποφασίζουν αν η διαδρομή κρατά: οι χώροι διευθύνσεων δεν πρέπει να επικαλύπτονται, και η ομάδα ασφαλείας δικτύου στο subnet του resolver πρέπει να δεχτεί το pool clients, που είναι απλώς άλλο ένα εύρος πηγών. Αποδείξτε το με έλεγχο effective route από την πλευρά του VM συν ένα άμεσο ερώτημα από τον client, ώστε πρόβλημα ζώνης, πρόβλημα επιθήματος ή φίλτρο να μη συγχέονται ποτέ με απόν transit.

Σχετικά άρθρα