Το DNS της VPN αναλαμβάνει κάθε αναζήτηση: διορθώστε το dns-priority στο NetworkManager
Μια σύνδεση VPN έχει από προεπιλογή προτεραιότητα 0 και διεκδικεί κάθε τομέα. Ορίστε αρνητική προτεραιότητα για τη σειρά και μετά χρησιμοποιήστε τομείς δρομολόγησης για να επιστρέψετε τα υπόλοιπα.
Συνδέστε το VPN του γραφείου και ξαφνικά κάθε αναζήτηση ονόματος πηγαίνει στον εταιρικό resolver. Τα δημόσια ονόματα εξακολουθούν να επιλύονται, οπότε τίποτα δεν φαίνεται χαλασμένο μέχρι να αποτύχει το όνομα ενός τοπικού εκτυπωτή ή μια εγγραφή split-horizon να επιστρέψει τη διεύθυνση του γραφείου. Σε ορισμένες εγκαταστάσεις Fedora συμβαίνει το αντίθετο: ο resolver του παρόχου συνεχίζει να απαντά αφού ανέβει η σήραγγα. Και τα δύο είναι ένα ερώτημα — ποιος resolver κατέχει αυτό το ερώτημα — και σε συστήματα NetworkManager η απάντηση ζει στις ιδιότητες DNS κάθε σύνδεσης.
Δύο συνδέσεις, ένας νικητής resolver
Κάθε σύνδεση δηλώνει προτεραιότητα DNS. Οι συνηθισμένες συνδέσεις έχουν από προεπιλογή 50 και οι συνδέσεις VPN 0, και κερδίζει η χαμηλότερη τιμή. Αυτή η προεπιλογή είναι ο λόγος που μια σύνδεση VPN ξεπερνά σιωπηλά την ενσύρματη για κάθε τομέα που διεκδικεί: το μηδέν κερδίζει το πενήντα χωρίς να το επιλέξει κανείς.
Η προτεραιότητα ταξινομεί τους υποψηφίους. Δεν περιορίζει για τι ρωτιέται ο νικητής. Μια σύνδεση VPN χωρίς τομέα αναζήτησης διεκδικεί τα πάντα, οπότε η προτίμησή της στέλνει και τα δημόσια ερωτήματα μέσα στη σήραγγα και, σε σχεδιασμό διαχωρισμένης σήραγγας, εκεί όπου προωθεί ο εταιρικός resolver.
Η προτεραιότητα αποφασίζει τη σειρά, η λίστα αναζήτησης την κυριότητα
nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf
Η λίστα αναζήτησης είναι η δήλωση κυριότητας. Ένας γυμνός τομέας όπως corp.example γίνεται κατάληξη αναζήτησης και τομέας δρομολόγησης. Η μορφή μόνο για δρομολόγηση ~corp.example στέλνει τις αναζητήσεις κάτω από αυτή την κατάληξη σε αυτή τη σύνδεση χωρίς να προσθέτει τον τομέα στα σύντομα ονόματα. Αυτό το tilde είναι η διαφορά μεταξύ «ρώτησε αυτόν τον διακομιστή» και «ρώτησε αυτόν τον διακομιστή και τελείωσε την πληκτρολόγησή μου».
Χρησιμοποιήστε και τις δύο μορφές όταν οι χρήστες πληκτρολογούν σύντομα ονόματα υπολογιστών και οι εγγραφές απευθύνονται και με πλήρως προσδιορισμένα ονόματα. Χρησιμοποιήστε μόνο τη μορφή δρομολόγησης όταν θέλετε τον διαχωρισμό χωρίς να αλλάξετε πώς ο resolver συμπληρώνει ένα γυμνό όνομα.
Στη συνέχεια κάντε την προτίμηση ρητή και επανενεργοποιήστε:
nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"
Η αρνητική προτεραιότητα είναι ο τεκμηριωμένος τρόπος να πείτε «προτίμησε αυτή τη σύνδεση», και ο ορισμός και των δύο οικογενειών διευθύνσεων κρατά τη συμπεριφορά συνεπή σε υπολογιστή με συνδεσιμότητα IPv6. Η αλλαγή της ιδιότητας χωρίς επανενεργοποίηση της σύνδεσης δεν αλλάζει τίποτα από όσα εκτελούνται τώρα, γι’ αυτό η ακολουθία τελειώνει με ρητό up.
Αφήστε το systemd-resolved να κρατήσει τον διαχωρισμό
Το προεπιλεγμένο πρόσθετο dnsmasq διοχετεύει τα ερωτήματα σε έναν τοπικό resolver, οπότε ο διαχωρισμός ανά ζεύξη παραμένει χονδρικός. Το systemd-resolved εκθέτει τον διαχωρισμό ανά ζεύξη, και το resolvectl query ονομάζει τη ζεύξη που απάντησε.
systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example
Έπειτα η εταιρική ζεύξη φέρει το corp.example και ένας δημόσιος resolver εξυπηρετεί τα υπόλοιπα. Όταν ένα ερώτημα φτάνει στη λάθος ζεύξη, η εντολή ονομάζει τη ζεύξη που το απάντησε, και το να το ξέρετε αυτό είναι καλύτερο από το να ξέρετε μόνο τη διεύθυνση.
Ταιριάξτε τον σχεδιασμό DNS με τον τύπο της σήραγγας
Οι σχεδιασμοί ιδιωτικότητας που στέλνουν τα πάντα μέσα από τη σήραγγα δεν πρέπει να φέρουν λίστα διαχωρισμού, γιατί θα επέστρεφε τα δημόσια ονόματα στον τοπικό resolver και θα ακύρωνε την πρόθεση. Οι σχεδιασμοί διαχωρισμένης σήραγγας χρειάζονται μία: χωρίς αυτήν ο εταιρικός resolver βλέπει κάθε δημόσιο ερώτημα και η ρύθμιση σπάει τη στιγμή που πέφτει η σήραγγα.
Έπειτα υπάρχει ο kill switch που μπλοκάρει το DNS εκτός σήραγγας. Τα ονόματα επιλύονται για τις ζώνες της σήραγγας και αποτυγχάνουν παντού αλλού ενώ η σύνδεση είναι απολύτως υγιής. Οι εφαρμόσιμες απαντήσεις είναι μια ρητή άδεια για τον resolver του LAN ή μια τοπική κρυφή μνήμη που προωθεί μόνο την εταιρική ζώνη, και καθεμία είναι εξαίρεση με ιδιοκτήτη και όχι σφάλμα στη σήραγγα.
Ένα προφίλ που ξαναγράφει τη διαμόρφωση του resolver κατά την εκκίνηση της διεπαφής συμπεριφέρεται σχεδόν το ίδιο: μόλις ο τοπικός resolver γίνει μη προσβάσιμος, θα επιλύονται μόνο τα ονόματα που γνωρίζει η σήραγγα. Όποιος μηχανισμός κι αν ισχύει, γράψτε ποια ονόματα πρέπει να λειτουργούν σε κάθε κατάσταση και δώστε αυτή τη λίστα σε όποιον χειρίζεται τις αναφορές.
Επαληθεύστε ανά ζεύξη και μετά ξανά μετά την επανασύνδεση
Ρωτήστε ένα εσωτερικό και ένα δημόσιο όνομα και δείτε πού πηγαίνει πραγματικά το ερώτημα. Μια σελίδα ελέγχου διαρροών σας λέει ποιος resolver απάντησε, όχι ποια ζεύξη επέλεξε το σύστημα, οπότε δεν λέει τίποτα για τη σειρά που μόλις ρυθμίσατε.
Εκτελέστε ξανά τα δύο ερωτήματα μετά από αποσύνδεση και επανασύνδεση. Οι προτεραιότητες εφαρμόζονται ξανά όταν ενεργοποιείται μια σύνδεση, και ένας παλιός συμβολικός σύνδεσμος μπορεί να επιβιώσει από μια αναβάθμιση που κανείς δεν θυμάται. Αυτό που θέλετε γραμμένο στο τέλος είναι ποιος resolver κατέχει ποια κατάληξη, μαζί με έναν έλεγχο που ισχύει και αύριο.