Γιατί το resolv.conf δείχνει το DNS του VPN σας αλλά οι αναζητήσεις το αγνοούν

Στα αρχεία καταγραφής τίποτα δεν φαίνεται λάθος: η διεπαφή είναι ενεργή, ο resolver αναφέρει τον διακομιστή DNS του VPN και το αρχείο στον δίσκο τον παραθέτει. Παρ' όλα αυτά, ένα εσωτερικό όνομα κεντρικού υπολογιστή εξακολουθεί να επιλύεται μέσω του τοπικού δρομολογητή. Οι τρεις δηλώσεις δεν αντιφάσκουν, επειδή το αρχείο, η κατάσταση ανά σύνδεση και η διαδρομή αναζήτησης είναι διαφορετικά αντικείμενα που τυχαίνει να μοιράζονται ένα όνομα. Ακολουθεί η διαδρομή που ακολουθεί πραγματικά ένα ερώτημα σε έναν υπολογιστή με systemd-resolved.

Τρία αντικείμενα που λέγονται resolv.conf

Σε έναν υπολογιστή με resolved, το /etc/resolv.conf είναι συνήθως συμβολικός σύνδεσμος προς το /run/systemd/resolve/stub-resolv.conf. Ο στόχος αυτός περιέχει τη διεύθυνση ενός τοπικού ακροατή stub, 127.0.0.53, καθώς και τους τομείς αναζήτησης που υπολόγισε το resolved. Είναι μια όψη της κατάστασης, όχι η ίδια η κατάσταση.

Η κατάσταση ζει στη διαμόρφωση του resolved ανά σύνδεση, γι' αυτό το resolvectl status μπορεί να διαφωνεί με το αρχείο και να έχει ακόμη δίκιο. Κάθε σύνδεση φέρει τους δικούς της διακομιστές και τους δικούς της τομείς δρομολόγησης, και το stub συμβουλεύεται αυτά τα δεδομένα όταν φτάνει ένα ερώτημα. Το εγχειρίδιο του systemd-resolved περιγράφει τα παραγόμενα αρχεία και το μοντέλο ανά σύνδεση· ο διαχωρισμός όψης και κατάστασης είναι το κομμάτι που αξίζει να κρατήσετε. Η αλλαγή του στόχου του συμβολικού συνδέσμου αλλάζει τι διαβάζουν οι παραδοσιακοί πελάτες, όχι τι γνωρίζει ο resolver.

Ένα τρίτο αντικείμενο, το /run/systemd/resolve/resolv.conf, ισοπεδώνει κάθε σύνδεση σε έναν κατάλογο διακομιστών. Ένα πρόγραμμα που δείχνει σε αυτό το αρχείο στέλνει ερωτήματα απευθείας στους καταγεγραμμένους διακομιστές και παρακάμπτει το stub, οπότε η πολιτική ανά σύνδεση δεν ισχύει πλέον γι' αυτό. Έτσι, δύο προγράμματα στο ίδιο μηχάνημα μπορούν να απαντούν διαφορετικά στο ίδιο όνομα, και κανένα από τα δύο δεν είναι χαλασμένο.

Παρακολουθήστε μία αναζήτηση μέσω του NSS

Το glibc διαβάζει το /etc/nsswitch.conf για να αποφασίσει ποιος απαντά σε ένα όνομα. Μια γραμμή hosts που περιέχει το resolve δρομολογεί την ερώτηση στο nss-resolve, το οποίο ρωτά το resolved μέσω D-Bus και λαμβάνει την απάντηση ανά σύνδεση. Μια γραμμή μόνο με το files dns στέλνει το ερώτημα στη διεύθυνση που κρατά το /etc/resolv.conf.

Αυτή η μία γραμμή εξηγεί τις περισσότερες διαφωνίες μεταξύ ενός περιηγητή και του dig. Το dig διαβάζει το resolv.conf απευθείας και δεν αγγίζει ποτέ το NSS, οπότε δοκιμάζει το stub ή έναν ανάντη διακομιστή αντί για τη διαδρομή που χρησιμοποιεί η εφαρμογή. Το getent hosts internal.example περνά από το NSS, και η σύγκριση της απάντησής του με εκείνη του dig είναι η πρώτη χρήσιμη μέτρηση.

Οι εφαρμογές που ενσωματώνουν δικό τους resolver ή μιλούν DNS over HTTPS με σταθερό τελικό σημείο παρακάμπτουν και τις δύο διαδρομές. Τίποτα στο resolv.conf ή στην κατάσταση του resolved δεν τις περιορίζει.

Ελέγξτε ποιος κατέχει το αρχείο και πού δείχνει

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

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Η πρώτη γραμμή εκτυπώνει τον σύνδεσμο και τον στόχο του μαζί, και ένα συνηθισμένο αρχείο που ανήκει σε σενάριο VPN σημαίνει ότι ο resolver δεν αντιμετωπίζει ποτέ αυτή την εγγραφή ως είσοδο. Η έξοδος κατάστασης παραθέτει διακομιστές ανά σύνδεση καθώς και τους τομείς δρομολόγησης που καθορίζουν πού πηγαίνει κάθε ερώτημα. Η γραμμή nsswitch λέει αν το stub συμβουλεύεται καθόλου, οπότε μια διεύθυνση stub στο αρχείο χωρίς resolve εκεί σημαίνει ότι τα ερωτήματα φτάνουν στον τοπικό ακροατή ενώ τίποτα δεν διαχειρίζεται τον διαχωρισμό. Και η τελευταία λίστα έχει σημασία, γιατί ένας υπολογιστής χωρίς stub-resolv.conf δεν εκτελεί τη διάταξη που περιγράφεται εδώ.

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

Επιδιόρθωση στον ιδιοκτήτη του συνδέσμου

Μια σύνδεση VPN θα πρέπει να καταχωρεί τους διακομιστές και τους τομείς της στη δική της σύνδεση και μετά να τους αποσύρει κατά την αποσύνδεση. Η ενσωμάτωση resolved του NetworkManager και ο δικός του βοηθός ενός πελάτη λειτουργούν έτσι· ένα σενάριο που απλώς ξαναγράφει το resolv.conf δεν το κάνει.

Σε μια σύνδεση που υπάρχει ήδη, οι ρυθμίσεις χρόνου εκτέλεσης δείχνουν τον μηχανισμό. Το resolvectl dns tun0 10.40.0.53 προσαρτά έναν διακομιστή, και το resolvectl domain tun0 '~corp.example' προσαρτά έναν τομέα δρομολόγησης. Η περισπωμένη είναι ο χαρακτήρας που σηκώνει το βάρος: περιορίζει τα ερωτήματα για αυτό το επίθημα σε αυτή τη σύνδεση και αφήνει όλα τα άλλα ήσυχα, ενώ η ίδια τιμή χωρίς αυτήν γίνεται τομέας αναζήτησης και ο διαχωρισμός εξατμίζεται. Αυτές οι διευθύνσεις είναι παραδείγματα εργαστηρίου, όχι μόνιμη διαμόρφωση. Επιβεβαιώστε με το resolvectl query host.corp.example και διαβάστε ποια σύνδεση απάντησε.

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

Πώς μοιάζει μια κατάσταση που λειτουργεί

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

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