Το DNS μέσω VPN λειτουργεί, αλλά τα ονόματα .local αποτυγχάνουν ακόμη: ποιος τα επιλύει;

Δύο μηχανήματα στο ίδιο VPN, ίδιο hostname, και μόνο ένα από αυτά το επιλύει: η διαφορά συνήθως δεν είναι η σήραγγα αλλά ποιος resolver απάντησε. Σε ένα Linux desktop το όνομα μπορεί να περάσει από τον διακόπτη υπηρεσιών ονομάτων, από το stub του systemd-resolved ή από έναν resolver που έφερε μαζί της η εφαρμογή, και καθένας από αυτούς εφαρμόζει τον δικό του κανόνα στο ίδιο επίθεμα. Το επίθεμα είναι εκεί όπου οι κανόνες αποκλίνουν, επειδή το .local δεν είναι ουδέτερη ετικέτα. Βρείτε ποια διαδρομή ακολουθεί πραγματικά το πρόγραμμα που αποτυγχάνει πριν αλλάξετε τη σειρά με την οποία εκτελείται οτιδήποτε.

Δύο resolvers, δύο διαφορετικές απαντήσεις

Μια παραδοσιακή αναζήτηση glibc διατρέχει τη γραμμή hosts: του nsswitch.conf και ρωτά κάθε module με τη σειρά μέχρι να απαντήσει ένα. Ένας client που μιλά στο systemd-resolved μέσω του stub listener ρωτά αντ’ αυτού μία μόνο διεργασία, και η διεργασία αυτή εφαρμόζει πολιτική ανά σύνδεσμο συν τις δικές της ειδικές περιπτώσεις. Μια εφαρμογή που φέρνει τον δικό της resolver ή συνδέει μια βιβλιοθήκη που το κάνει μπορεί να παρακάμψει και τους δύο. Ένα hostname μπορεί επομένως να έχει τρεις ιδιοκτήτες σε ένα μηχάνημα, και μόνο ένας από αυτούς ξέρει τι σκόπευε το VPN.

Προσδιορίστε τον ιδιοκτήτη πριν αλλάξετε οτιδήποτε, γιατί η διόρθωση διαφέρει για καθέναν από τους τρεις. Ένας browser και ένα εργαλείο γραμμής εντολών στο ίδιο desktop μπορούν νόμιμα να διαφωνούν, και αυτή η διαφωνία είναι το στοιχείο και όχι το σφάλμα. Αν ο browser επιλύει το όνομα και το εργαλείο όχι, κάνετε debugging σε διαδρομή resolver και όχι σε διαδρομή VPN. Επιβεβαιώστε τη διαδρομή ξεχωριστά, ώστε ένα σφάλμα δρομολόγησης να μη συγχέεται με σφάλμα υπηρεσίας ονομάτων. Όταν και τα δύο συμφωνούν, το σφάλμα βρίσκεται πάνω από τον host και η διαμόρφωση του resolver εδώ δεν αξίζει άλλη επεξεργασία.

Ποια εντολή ρώτησε πραγματικά τον resolver σας

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Η πρώτη ρωτά μέσω των διαμορφωμένων modules, που είναι αυτό που βιώνει ένα τυπικό πρόγραμμα. Η δεύτερη ρωτά απευθείας το systemd-resolved και αναφέρει τον σύνδεσμο, το πρωτόκολλο και τον server που απάντησε. Το ερώτημα στον εταιρικό server βάσει διεύθυνσης αποδεικνύει μόνο ότι ο server κρατά την εγγραφή, γιατί δεν λέει τίποτα για το αν η εφαρμογή τον ρώτησε ποτέ. Διαβάστε τον σύνδεσμο που μεταφέρει το VPN και τους τομείς που διεκδικεί, και μετά συγκρίνετε αυτή τη λίστα με το επίθεμα στο όνομα που αποτυγχάνει.

Γιατί το .local προσπερνά τη ζώνη unicast σας

την αναφορά του systemd-resolved αναφέρει ότι ονόματα με πολλαπλές ετικέτες που τελειώνουν σε .local πηγαίνουν συνήθως σε multicast DNS όταν το mDNS είναι ενεργό, αντί σε συνηθισμένο unicast DNS. Το RFC 6762 κρατά αυτόν τον χώρο ονομάτων για link-local multicast, οπότε μια εταιρική ζώνη μπορεί να κρατά σωστή εγγραφή που δεν ερωτάται ποτέ για αυτό το επίθεμα. Η σήραγγα μπορεί να δρομολογήσει τον resolver τέλεια και παρόλα αυτά να χάσει την κούρσα. Ένα επιτυχές ping από cache δεν λέει τίποτα για την αναζήτηση που μόλις έγινε.

Υπάρχει μια τεκμηριωμένη εξαίρεση, και λύνει τις περισσότερες από αυτές τις περιπτώσεις: όταν ένας σύνδεσμος δηλώνει αυτό το επίθεμα ως τομέα αναζήτησης ή τομέα δρομολόγησης, ο daemon το κρατά στη διαδρομή unicast και προσπερνά την ειδική περίπτωση multicast. Αυτή είναι πολιτική ανά σύνδεσμο και όχι καθολική προτίμηση. Δύο μηχανήματα με τον ίδιο VPN server μπορούν να συμπεριφέρονται διαφορετικά όταν ένα προφίλ δικτύου δηλώνει τον τομέα και το άλλο όχι, οπότε διαβάστε το ενεργό προφίλ και όχι αυτό που θυμάστε ότι επεξεργαστήκατε.

Η στενή εξαίρεση νικά μια καθολική αναδιάταξη

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

Επιβιώνει επίσης από μια αποσύνδεση, γιατί η πολιτική του συνδέσμου εφαρμόζεται ξανά όταν ο σύνδεσμος επιστρέψει. Η επεξεργασία του κοινού nsswitch.conf είναι η δελεαστική και η ακριβότερη εναλλακτική, γιατί αλλάζει τη συμπεριφορά αναζήτησης για κάθε όνομα στο μηχάνημα, μαζί με την τοπική ανακάλυψη. Η απενεργοποίηση του daemon multicast δεν είναι επίσης ισοδύναμη: αφαιρεί την τοπική συμπεριφορά χωρίς να διδάξει σε κανέναν resolver την εταιρική ζώνη. Αν η υπηρεσία είναι νέα και όχι κληρονομημένη, βάλτε την κάτω από έναν υποτομέα που ελέγχει ο οργανισμός σας και προσπεράστε τον ανταγωνισμό εντελώς. Επιλέξτε τη στενή εξαίρεση όταν το όνομα είναι καθηλωμένο στο firmware ή τυπωμένο σε ετικέτα, και επιλέξτε νέο υποτομέα όταν ελέγχετε ακόμη τον client.

Τι να αποδείξετε μετά την αλλαγή

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Μια σωστή διεύθυνση με λάθος πιστοποιητικό εξακολουθεί να αποτυγχάνει σε έναν αυστηρό client, οπότε ελέγξτε το όνομα που περιμένει η εφαρμογή όταν η επίλυση λειτουργήσει. Επιβεβαιώστε ότι η υπηρεσία δέχεται συνδέσεις από τη διεύθυνση VPN και όχι μόνο από το εύρος του γραφείου. Γράψτε το εύρος του τομέα, τον server και τον ιδιοκτήτη στην τεκμηρίωση της σύνδεσης. Διαφορετικά, ο επόμενος άνθρωπος που θα συναντήσει αυτή την αποτυχία θα φτάσει στην ίδια καθολική επεξεργασία που μόλις αποφύγατε.