Το DNS που προωθεί το OpenVPN αγνοείται: ποιο στοιχείο το εφαρμόζει

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

Μια προωθούμενη επιλογή είναι προσφορά, όχι εγκατάσταση

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

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Ο πελάτης δεν λαμβάνει ρυθμισμένο resolver. Λαμβάνει μεταβλητές περιβάλλοντος, foreign_option_1 και επόμενες, μία για κάθε προωθούμενη γραμμή, και κάτι τοπικό πρέπει να τις διαβάσει και να ξαναγράψει την κατάσταση του resolver του λειτουργικού συστήματος. Στο Linux τίποτα δεν το κάνει εξ ορισμού, γι' αυτό ένας σωστός διακομιστής και ένας συνδεδεμένος πελάτης μπορούν ακόμη να επιλύουν μέσω του LAN.

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

Επιβεβαιώστε ότι έφτασε το push και βρείτε τον ιδιοκτήτη

Ξεκινήστε ονομάζοντας τον εκκινητή: μια γυμνή openvpn εντολή, ένα στιγμιότυπο systemd, το NetworkManager ή έναν πελάτη κατασκευαστή. Αυτό καθορίζει πού μπορεί να ζήσει ένα hook. Σε κεντρικό υπολογιστή με systemd-resolved, resolvectl status απαριθμεί κάθε ζεύξη με τους διακομιστές DNS και τους τομείς αναζήτησης που πραγματικά χρησιμοποιεί, και η ζεύξη του τούνελ δεν ονομάζεται πάντα tun0.

Αν η προωθούμενη διεύθυνση εμφανίζεται στο αρχείο καταγραφής αλλά όχι σε καμία ζεύξη, λείπει η ενσωμάτωση. Αν εμφανίζεται στη ζεύξη και τα ερωτήματα φεύγουν αλλού, το πρόβλημα είναι ποια ερωτήματα επιλέγουν αυτή τη ζεύξη. Το NetworkManager dns=dnsmasq στο αρχείο /etc/NetworkManager/NetworkManager.conf τρέχει έναν τοπικό προωθητή που εφαρμόζει διαχωρισμένο DNS σκόπιμα: τα ονόματα εντός του τομέα VPN πηγαίνουν στον resolver του VPN, όλα τα άλλα κρατούν την προηγούμενη διαδρομή. Αυτή η συμπεριφορά μοιάζει με βλάβη όταν περιμένατε να μετακινηθεί όλη η κίνηση· ελέγξτε τις ρυθμίσεις ανά σύνδεση με nmcli connection show "My VPN", όπου ipv4.dns και ipv4.dns-search κρατούν τις τιμές πίσω από ό,τι αναφέρει η συσκευή, πριν το χαρακτηρίσετε χαλασμένο. Αν κάθε ερώτημα πρέπει πραγματικά να φτάνει στον resolver του VPN, αφαιρέστε dns=dnsmasq από NetworkManager.conf και επανεκκινήστε το NetworkManager, που επιστρέφει την επίλυση στις ρυθμίσεις της σύνδεσης· αλλιώς κρατήστε τον διαχωρισμένο DNS και διορθώστε τη λίστα τομέων που προωθείται.

Linux: δώστε τις επιλογές στον resolver

Τα πακέτα των διανομών παρέχουν ένα hook γι' αυτό, και πρέπει να επιτραπεί στον πελάτη να το εκτελέσει. Μια τυπική διάταξη σε κεντρικό υπολογιστή χωρίς systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Με systemd-resolved το παλαιότερο σενάριο resolv.conf μπορεί να μην αλλάξει τίποτα ουσιαστικό, γιατί ο stub resolver κρατά κατάσταση ανά ζεύξη. update-systemd-resolved ο βοηθός τεκμηριώνει μια μορφή hook που χρησιμοποιεί up-restart και down-pre, κάτι που μετρά όταν μια διεπαφή επιβιώνει μιας μόνο απόπειρας σύνδεσης. Ό,τι κι αν επιλέξετε, ένα στοιχείο πρέπει να κατέχει την κατάσταση. Η προσθήκη ενός άσχετου hook δίπλα στο NetworkManager δίνει δύο συγγραφείς στην ίδια ζεύξη, και τότε το αποτέλεσμα εξαρτάται από τη σειρά και όχι από τη διαμόρφωσή σας.

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

Τα Windows και το macOS εφαρμόζουν διαφορετικά μέρη

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

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Αν λείπει η διεύθυνση, ορίστε την με Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, μετά προσθέστε το επίθημα στις ιδιότητες IPv4 του προσαρμογέα ώστε fileserver να γίνει fileserver.corp.example. Μια τιμή SearchList για όλο το μηχάνημα κάτω από Tcpip\Parameters κάνει το ίδιο. Όπου το μακρύ όνομα επιλύεται και το γυμνό όχι, ο resolver είναι ήδη σωστός και φταίει η λίστα αναζήτησης. Οι διορθώσεις, με σειρά: προωθήστε ένα DOMAIN ώστε ο πελάτης να μάθει το επίθημα, προσθέστε το επίθημα στη λίστα αναζήτησης του προσαρμογέα ή της σύνδεσης, και ως προσωρινό μέτρο καρφώστε το όνομα στο hosts, ή στο LMHOSTS στα Windows· η περιήγηση NetBIOS δεν διασχίζει δρομολογητή, οπότε η εκπομπή που βρίσκει ένα σύντομο όνομα στο LAN του γραφείου δεν φτάνει ποτέ σε πελάτη τούνελ.

block-outside-dns Το block-outside-dns είναι συμπεριφορά του πελάτη Windows, όχι φορητή γραμμή προφίλ, και η αντιγραφή του σε προφίλ Linux ή macOS δεν το αναπαράγει εκεί. Αν τα δημόσια ονόματα δουλεύουν και τα εσωτερικά αποτυγχάνουν στα Windows, συγκρίνετε τη σειρά προσαρμογέων στις Σύνθετες ρυθμίσεις με ipconfig /all. Στο macOS η σειρά resolver ανά υπηρεσία ανήκει στο σύστημα, γι' αυτό χρησιμοποιήστε scutil --dns για να δείτε ποιος resolver ρωτιέται για ποιον τομέα, και αντιμετωπίστε κάθε μεμονωμένη αναφερόμενη διόρθωση προφίλ ως εξαρτώμενη από τον πελάτη και όχι γενική.

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

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

Αποδείξτε πού πήγε το ερώτημα

Μια καταγραφή κατά τη διάρκεια μιας αναζήτησης λύνει τη διαφωνία: tcpdump -ni eth0 port 53 δείχνει ερωτήματα στη φυσική διεπαφή, που σημαίνει ότι φεύγουν εκτός τούνελ και ο resolver δεν άλλαξε ποτέ. dig @10.8.0.1 name.corp.example μετά διαχωρίζει τις δύο εναπομένουσες περιπτώσεις. Αν το άμεσο ερώτημα απαντά, ο resolver δουλεύει και ο πελάτης δεν τον χρησιμοποιεί· αν λήξει, ο resolver είναι απρόσιτος μέσω του τούνελ και καμία τοπική αλλαγή δεν θα βοηθήσει.

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

Η προσβασιμότητα περιλαμβάνει το τείχος προστασίας στον κεντρικό υπολογιστή VPN, που πρέπει να επιτρέπει UDP και TCP 53 από τη δεξαμενή. Μια κλειστή θύρα μοιάζει ακριβώς με χαλασμένο push, και το ίδιο ένας resolver που απαντά μόνο από το εσωτερικό του δικτύου τούνελ. Επαναλάβετε την καταγραφή μετά από μία αποσύνδεση και επανασύνδεση, γιατί ρυθμίσεις που εμφανίζονται στην πρώτη σύνδεση και εξαφανίζονται στη δεύτερη είναι σφάλμα κύκλου ζωής στο hook, όχι επιλογή που λείπει.

Κρατήστε έναν ιδιοκτήτη και επαληθεύστε με σειρά

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

Κλείστε τον κύκλο με τέσσερις ελέγχους: η προωθούμενη διεύθυνση παρούσα στη ζεύξη του τούνελ, το εσωτερικό όνομα να επιλύεται ως πλήρως προσδιορισμένο όνομα, το ίδιο όνομα να επιλύεται χωρίς το επίθημα, και τα δύο να ισχύουν ακόμη μετά από μία επανασύνδεση. Μια καταγραφή σας λέει ποιος από τους τέσσερις απέτυχε. Το εγχειρίδιο του OpenVPN 2.6 απαριθμεί dhcp-option και τις οδηγίες σεναρίων με τις σημειώσεις πλατφόρμας τους.