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

Διορθώστε τη λίστα σκόπιμα και μετά ασχοληθείτε χωριστά με τον μηχανισμό push. Οι διαδρομές είναι τρίτο θέμα και όχι αυτό που διορθώνεται εδώ.

Ποια λίστα χρησιμοποιούν πραγματικά οι εφαρμογές

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

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

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

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

Αφαιρέστε τους pushed διακομιστές ή κατατάξτε τους χαμηλότερα

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Το ευρετήριο 1 συμβουλεύεται πρώτο, οπότε οι pushed διευθύνσεις μένουν διαθέσιμες αλλά παύουν να είναι η προεπιλεγμένη απάντηση σε κάθε ερώτημα. Η σημαία validate=no παρακάμπτει έναν έλεγχο προσβασιμότητας που συχνά αποτυγχάνει όσο η σήραγγα ακόμη σταθεροποιείται, οπότε επιβεβαιώστε το αποτέλεσμα με την εντολή show αντί να εμπιστευτείτε τον κωδικό εξόδου.

Δύο όρια αξίζει να τα ξέρετε πριν βασιστείτε σε αυτό. Τα Windows δεν θα διαγράψουν διακομιστές που ήρθαν μέσω DHCP μέσα από το netsh, και αυτές οι τιμές παραμένουν ως DhcpNameServer κάτω από το κλειδί μητρώου της διεπαφής, οπότε η επεξεργασία μητρώου είναι τελευταία λύση που πρέπει να ελεγχθεί ξανά μετά την επόμενη μίσθωση. Η σειρά σύνδεσης των προσαρμογέων επίσης δεν είναι αξιόπιστος μηχανισμός κατάταξης, γιατί ένας πελάτης VPN μπορεί να εισαγάγει τη δική του καταχώριση στην κορυφή της λίστας.

Πού μπορεί να φιλτραριστεί το push

Μια καλύτερη διόρθωση αφαιρεί την επιλογή πριν εφαρμοστεί. Ο πελάτης Community OpenVPN μπορεί να φιλτράρει μια pushed οδηγία με βάση το όνομα, κάτι που αφήνει τη διαμόρφωση του διακομιστή ανέγγιχτη.

pull-filter ignore "dhcp-option DNS "

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

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

Κάντε τη διόρθωση να επιβιώσει μιας επανασύνδεσης

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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

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