Λάθος διακομιστής DNS σε VPN των Windows: μέτρο, σειρά σύνδεσης ή επίθημα

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

Τρεις μηχανισμοί αποφασίζουν, και συνήθως ένας είναι λάθος

Το μέτρο της διεπαφής ταξινομεί τους προσαρμογείς για μια δεδομένη οικογένεια διευθύνσεων. Η σειρά σύνδεσης κάτω από Tcpip\Linkage είναι μια λίστα αναγνωριστικών διεπαφής για όλο το μηχάνημα, την οποία παλιές διαδρομές κώδικα ακόμη συμβουλεύονται. Ο Πίνακας Πολιτικής Ανάλυσης Ονομάτων (NRPT) δεσμεύει έναν χώρο ονομάτων σε συγκεκριμένους διακομιστές, και η λίστα επιθημάτων αποφασίζει αν ένα σύντομο όνομα επεκτείνεται καθόλου. Είναι ανεξάρτητοι, και γι' αυτό ένας σωστός resolver στον προσαρμογέα VPN χάνει από μια παρωχημένη προτίμηση αλλού.

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

Απόφαση πρώτη: μπορεί ο προωθημένος resolver να απαντήσει καθόλου;

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

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Αν το πρώτο πετύχει και το δεύτερο αποτύχει, ο resolver είναι προσβάσιμος και τα Windows επιλέγουν άσχημα· πηγαίνετε στις αποφάσεις για χώρο ονομάτων και σειρά παρακάτω. Αν αποτύχει και το πρώτο, τίποτα στον πελάτη δεν θα βοηθήσει: ελέγξτε ότι UDP και TCP 53 φτάνουν στον διακομιστή μέσα από τη σήραγγα, ότι κανένα τείχος προστασίας του κεντρικού υπολογιστή στον διακομιστή δεν απορρίπτει τη δεξαμενή, και ότι οι δικοί του προωθητές είναι υγιείς.

Σταματήστε σε αυτή τη διακλάδωση. Η εφαρμογή κανόνα NRPT σε resolver που δεν μπορείτε να φτάσετε παράγει την ίδια αστοχία με περισσότερη διαμόρφωση για αναίρεση, και κρύβει το πραγματικό σφάλμα πίσω από έναν κανόνα που δείχνει έγκυρος.

Απόφαση δεύτερη: ένας χώρος ονομάτων ή κάθε ερώτημα;

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

Ορίστε το μέτρο ανά οικογένεια διευθύνσεων, και στις δύο διεπαφές, και επιβεβαιώστε μετά τη σειρά:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Αντικαταστήστε το 11 με το ifIndex του προσαρμογέα της σήραγγας από τη γραμμή πάνω· αν το 11 είναι ο προσαρμογέας LAN, η ίδια εντολή χαμηλώνει τη λάθος διαδρομή. Αν ανυψώσετε αντίθετα τον προσαρμογέα LAN, φτάνετε στην ίδια σειρά από την άλλη πλευρά: netsh int ip set interface interface="Ethernet" metric=15, και netsh int ipv6 set interface interface="Ethernet" metric=15 για τη δεύτερη οικογένεια, γιατί το int ip αγγίζει μόνο IPv4.

Η σειρά σύνδεσης είναι το τελευταίο καταφύγιο και όχι η πρώτη κίνηση. Το HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage κρατά μια λίστα Bind με αναγνωριστικά συσκευών, και το να φέρετε το αναγνωριστικό της σήραγγας μπροστά αλλάζει όντως ποιος προσαρμογέας ρωτιέται πρώτος, αλλά είναι τιμή μητρώου για όλο το μηχάνημα χωρίς εύρος ανά χώρο ονομάτων. Εξάγετέ την πριν την επεξεργασία και επανασυνδέστε τη σήραγγα μετά, ώστε η σειρά να ισχύει στην κατάσταση που περιμένει ο πελάτης.

Για έναν μόνο χώρο ονομάτων, προτιμήστε το στενότερο εργαλείο:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Απόφαση τρίτη: επιβιώνει η διόρθωση σε μια επανασύνδεση;

Ένα μέτρο που λειτουργεί μέχρι την επόμενη σύνδεση μέσω τηλεφωνικής γραμμής δεν αποθηκεύτηκε ποτέ. Το L2TP/IPsec και άλλα προφίλ σύνδεσης δημιουργούνται ξανά όταν ξεκινά η σύνδεση, οπότε η αποθηκευμένη τιμή ζει στην καταχώριση του τηλεφωνικού καταλόγου ως IpInterfaceMetric, όχι μόνο στη ζωντανή διεπαφή. Κάποια περιβάλλοντα γράφουν αυτό το πεδίο με σενάριο ακριβώς για αυτόν τον λόγο· άλλα σπρώχνουν την προτίμηση από πολιτική διαχείρισης και αφήνουν το τελικό σημείο ήσυχο.

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

ipconfig /registerdns
ipconfig /flushdns

Υπάρχει διακόπτης στο ίδιο επίπεδο. Η απενεργοποίηση της δυναμικής εγγραφής στον φυσικό προσαρμογέα σταματά τον πελάτη να διαφημίζει τη διεύθυνσή του από την πλευρά του VPN με λάθος όνομα, κάτι που είναι διαφορετική επισκευή από την ανανέωση παραπάνω.

Το IPv6 αξίζει τη δική του γραμμή στην απόφαση. Αν ο φυσικός προσαρμογέας έχει καθολική διεύθυνση IPv6 ενώ η σήραγγα μεταφέρει μόνο IPv4, τα Windows μπορεί να προτιμήσουν τη διαδρομή χωρίς σήραγγα για την ανάλυση ονομάτων. Ελέγξτε αυτή την οικογένεια χωριστά, γιατί ένα μέτρο που ορίστηκε για IPv4 δεν λέει τίποτα γι' αυτήν:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Η απενεργοποίηση του IPv6 στον προσαρμογέα LAN αφαιρεί αυτή τη διαδρομή και το πρωτόκολλο μαζί της· μια αλλαγή μέτρου στη διεπαφή IPv6, ή ένας κανόνας NRPT για τον εταιρικό χώρο ονομάτων, κρατά την οικογένεια και διορθώνει την προτίμηση. Διαλέξτε το στενότερο, εκτός αν έχετε αποφασίσει ότι αυτός ο σύνδεσμος δεν πρέπει να έχει IPv6.

Επαληθεύστε με ονομασμένη πηγή, και κρατήστε έναν υπεύθυνο

Επαληθεύστε με εργαλεία που αναφέρουν ποια πηγή ισχύει, όχι μόνο αν φορτώνει μια σελίδα:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Έπειτα διαχωρίστε το φιλτράρισμα από την επιλογή, γιατί από μέσα σε μια εφαρμογή φαίνονται ίδια. Το block-outside-dns του OpenVPN μπλοκάρει τη θύρα 53 στους άλλους προσαρμογείς· δεν διαλέγει resolver. Αν τώρα κάθε ερώτημα αποτυγχάνει, ένα φίλτρο μπορεί να μπλοκάρει τον μόνο προσβάσιμο διακομιστή· αν ο ρυθμισμένος resolver αγνοείται, η σειρά ή ο κανόνας χώρου ονομάτων είναι λάθος. Η αλλαγή και των δύο μαζί κάνει ένα μπλοκαρισμένο και ένα αγνοημένο ερώτημα δυσδιάκριτα.

Κρατήστε έναν υπεύθυνο για την πολιτική DNS: το προφίλ VPN, μια πολιτική διαχείρισης ή έναν κανόνα NRPT, όχι δύο από αυτά. Πριν το κλείσετε:

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

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