Το Azure P2S VPN δεν μπορεί να επιλύσει όνομα ιδιωτικού τελικού σημείου

Συνδέετε το τούνελ point-to-site, κάνετε ping στην ιδιωτική διεύθυνση, ανοίγετε την εφαρμογή και παίρνετε 403 ή σφάλμα πιστοποιητικού. Και τα δύο συμπτώματα δείχνουν στο DNS, αλλά είναι διαφορετικές βλάβες: το ένα σημαίνει ότι ο πελάτης επέλυσε τη δημόσια διεύθυνση, το άλλο ότι επέλυσε την ιδιωτική διεύθυνση και μετά πρόσφερε όνομα που δεν καλύπτει το πιστοποιητικό. Περάστε τους ελέγχους παρακάτω με σειρά και σταματήστε στην πρώτη αποτυχία, γιατί μια καταχώριση hosts ή μια αποθηκευμένη απάντηση μπορεί να κάνει κάθε επόμενο έλεγχο να περάσει για λάθος λόγο. Κρατώ αυτή τη σειρά σε αρχείο κειμένου δίπλα στα προφίλ VPN μου, γιατί η διόρθωση δεν αλλάζει τίποτα στο τούνελ και τα πάντα σε ό,τι γνωρίζει ο πελάτης.

Ξεκινήστε από τη διεύθυνση που παίρνει πραγματικά ο πελάτης

Ρωτήστε τον resolver απευθείας αντί να εμπιστευτείτε την εφαρμογή. Στα Windows, το nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net δείχνει ποια όψη έλαβε ο πελάτης. Μια δημόσια απάντηση σημαίνει ότι τίποτα πιο κάτω δεν θα φτάσει στο τελικό σημείο· η ιδιωτική διεύθυνση του τελικού σημείου σημαίνει ότι το DNS τελείωσε και ο επόμενος έλεγχος είναι η ίδια η σύνδεση.

Ένα ιδιωτικό τελικό σημείο δεν μετονομάζει την υπηρεσία. Ο λογαριασμός ή η εφαρμογή διατηρεί το συνηθισμένο πλήρως αναγνωρισμένο όνομά του, και το τελικό σημείο αλλάζει μόνο τη διεύθυνση στην οποία επιλύεται αυτό το όνομα για πελάτες μέσα στο εικονικό δίκτυο. Γι' αυτό το ίδιο όνομα κεντρικού υπολογιστή επιλύεται ιδιωτικά από VM στο δίκτυο και δημόσια από φορητό που δεν έλαβε ποτέ την ιδιωτική όψη.

Ελέγξτε τη ζώνη, τη σύνδεσή της και την εγγραφή πριν από το τούνελ

Τρεις συνθήκες πρέπει να ισχύουν μαζί: η ιδιωτική ζώνη υπάρχει, είναι συνδεδεμένη με το εικονικό δίκτυο όπου μπαίνουν στο Azure η πύλη VPN και οι πελάτες, και περιέχει εγγραφή A για το τελικό σημείο που δείχνει στην ιδιωτική διεύθυνση. Συνδέστε τη ζώνη σε άσχετο δίκτυο και η πύλη θα συνεχίσει να επιλύει τη δημόσια εγγραφή ενώ όλα στο τούνελ θα φαίνονται υγιή.

Τα ονόματα ζωνών ανήκουν σε υπηρεσίες, όχι γενικά σε ιδιωτικούς συνδέσμους. Το App Service χρησιμοποιεί συνήθως privatelink.azurewebsites.net, η αποθήκευση και το SQL έχουν δικούς τους χώρους ονομάτων, και ο δανεισμός ζώνης άλλης υπηρεσίας παράγει ζώνη που υπάρχει και δεν απαντά τίποτα χρήσιμο.

Δώστε στον πελάτη resolver που μπορεί πραγματικά να φτάσει

Το 168.63.129.16 απαντά από εικονικές μηχανές Azure και δεν είναι διακομιστής DNS για φορητό στην άλλη πλευρά ενός τούνελ point-to-site. Ο πελάτης χρειάζεται resolver προσβάσιμο μέσω του τούνελ: τελικό σημείο εισερχόμενης κίνησης του Azure DNS Private Resolver, προωθητή μέσα στο εικονικό δίκτυο, ή καταχωρίσεις διακομιστή DNS που μεταφέρονται στο προφίλ πελάτη VPN ώστε ο πελάτης να ρωτά απευθείας το εικονικό δίκτυο.

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

Αν προωθείτε αντί να σπρώχνετε ρυθμίσεις, προωθήστε τον χώρο ονομάτων που κατέχει η ιδιωτική ζώνη, privatelink.azurewebsites.net αντί για ολόκληρο το azurewebsites.net. Ένας υπό όρους προωθητής που καταπίνει ολόκληρο το γονικό επίθημα στέλνει κάθε αναζήτηση της υπηρεσίας στο Azure, μαζί με όσες θα έπρεπε να μείνουν τοπικές.

Χρησιμοποιήστε το όνομα για το οποίο εκδόθηκε το πιστοποιητικό

Όταν η διεύθυνση είναι σωστή, εμφανίζεται η δεύτερη βλάβη. Η αποθήκευση και το App Service δημοσιεύουν ψευδώνυμο privatelink, και αυτό το ψευδώνυμο δεν είναι απαραίτητα το όνομα στο πιστοποιητικό. Μια μεταφόρτωση AzCopy προς το privatelink.blob.core.windows.net απέτυχε στην επικύρωση· η ίδια μεταφόρτωση προς το <account>.blob.core.windows.net/<container> επιλύθηκε στην ιδιωτική διεύθυνση και πέρασε, οπότε έμεινε στην ιδιωτική διαδρομή χωρίς παράκαμψη.

Ο κανόνας ισχύει στο πρόγραμμα περιήγησης και για το App Service: συνδεθείτε με το όνομα κεντρικού υπολογιστή που καλύπτει το πιστοποιητικό και αφήστε το DNS να δώσει την ιδιωτική διεύθυνση. Μην καταφύγετε σε παράκαμψη επικύρωσης, γιατί μετατρέπει ένα λάθος ονοματοδοσίας σε οπισθοδρόμηση ασφαλείας. Ένα επιτυχές ping αποδεικνύει τη διαδρομή και δεν λέει τίποτα για το όνομα μέσα στη χειραψία, γι' αυτό μένουν ξεχωριστοί έλεγχοι.

Μια σειρά τεσσάρων βημάτων που απομονώνει κάθε επίπεδο

1. Επιβεβαιώστε ότι ο πελάτης VPN έχει διεύθυνση από τη δεξαμενή point-to-site και διαδρομή προς την ιδιωτική διεύθυνση του τελικού σημείου.
2. Επιλύστε το ακριβές όνομα που χρησιμοποιεί η εφαρμογή και συγκρίνετε την απάντηση με τη διεύθυνση του τελικού σημείου.
3. Ανοίξτε σύνδεση TCP προς το τελικό σημείο στη θύρα της υπηρεσίας και μετά διαβάστε το όνομα πιστοποιητικού που παρουσιάζεται σε αυτή τη σύνδεση.
4. Μόνο τώρα δοκιμάστε την εξουσιοδότηση, γιατί μια διαδρομή που δουλεύει και ένα έγκυρο πιστοποιητικό ακόμη δεν δίνουν πρόσβαση στον πόρο.

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

Χρησιμοποιήστε ένα VM μέσα στο εικονικό δίκτυο ως έλεγχο. Αν το όνομα επιλύεται εκεί ιδιωτικά και δημόσια από το τούνελ, η ζώνη και η εγγραφή είναι σωστές και η μόνη διαφορά είναι η διαδρομή resolver του πελάτη, που επιβεβαιώνεται γρηγορότερα από άλλο ένα πέρασμα στη διαμόρφωση του τελικού σημείου.

Οι πελάτες κάνουν και cache. Μια εγγραφή που απάντησε δημόσια πριν από δέκα λεπτά συνεχίζει να απαντά αφού διορθώσετε τη ζώνη, οπότε καθαρίστε την πριν από τη νέα δοκιμή. Στα Windows, το ipconfig /flushdns καθαρίζει την cache του πελάτη· οι κανόνες πολιτικής επίλυσης ονομάτων παραμένουν, αποφασίζουν ποιο επίθημα πάει σε ποιον διακομιστή και μπορεί να συνεχίσουν να στέλνουν τον χώρο ονομάτων στον resolver που μόλις αντικαταστήσατε.

Πού ανήκει μια καταχώριση hosts

Το να προσθέσετε τη διεύθυνση του τελικού σημείου σε αρχείο hosts είναι καλή διάγνωση και κακός σχεδιασμός. Αποδεικνύει ότι λείπει η αντιστοίχιση ονόματος σε διεύθυνση και σας αφήνει να δοκιμάσετε τα πάντα μετά από αυτό το βήμα, αλλά είναι αόρατο στους χρήστες σας, σπάει όταν αλλάζει η διεύθυνση του τελικού σημείου και κρύβει τη ζώνη που θα έπρεπε να απαντά.

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

Τα σύντομα ονόματα χρειάζονται επίθημα αναζήτησης και τα πλήρως αναγνωρισμένα όχι, οπότε δοκιμάστε πρώτα το πλήρως αναγνωρισμένο όνομα και μετά αποφασίστε αν η ροή εργασίας χρειάζεται επίθημα που σπρώχνεται μέσω του προφίλ πελάτη. Η Microsoft τεκμηριώνει τα ονόματα ζωνών και τις μορφές εγγραφών ανά υπηρεσία στις οδηγίες DNS για ιδιωτικά τελικά σημεία· διαβάστε την καταχώριση για τη δική σας υπηρεσία αντί να αντιγράψετε ζώνη από άλλη.