Σηκώσατε το WireGuard, η σήραγγα περνά κίνηση, και το εσωτερικό όνομα ακόμη δεν επιλύεται. Η επόμενη κίνηση είναι συνήθως να ψάξετε για ρύθμιση DNS στη διαμόρφωση του WireGuard, σαν να μπορούσε ένα peer να σπρώξει έναν resolver όπως κάνουν άλλα VPN. Δεν μπορεί. Η χειραψία μεταφέρει κλειδιά, διευθύνσεις διασύνδεσης και επιτρεπόμενες IP, και δεν έχει πεδίο για διακομιστές DNS ή τομείς αναζήτησης. Η πολιτική του resolver ζει στον πελάτη, και εκεί ανήκει η διόρθωση.

Η σήραγγα και ο resolver είναι ξεχωριστά συμβόλαια

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

Άρα μια σήραγγα που δουλεύει δεν σας λέει τίποτα για την επίλυση ονομάτων. Ο πελάτης μπορεί να έχει τέλεια διαδρομή προς 10.90.0.1 και ακόμη να στέλνει τα ερωτήματά του σε δημόσιο resolver, γι' αυτό το σύμπτωμα μοιάζει με “το VPN χάλασε το DNS”, ενώ το DNS δεν είχε ποτέ δείξει προς το VPN.

Σερβίρετε τη ζώνη χωρίς να γίνετε αναδρομικός resolver

Η πλευρά του διακομιστή είναι μια μικρή αυθεντική ζώνη, όχι ένας γενικός resolver. Σε αυτό το παράδειγμα η πύλη είναι 10.90.0.1, οι πελάτες είναι 10.90.0.0/24, και η εφαρμογή που σας ενδιαφέρει απαντά στο 10.60.0.20.

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

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Έπειτα δηλώστε τη ζώνη και το αρχείο της:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

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

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Ανοίξτε UDP και TCP 53 μόνο στη διασύνδεση του VPN. Το να δημοσιεύσετε μια ιδιωτική αρχή στη δημόσια διασύνδεση προσκαλεί και ερωτήματα και απαρίθμηση, και το allow-transfer πρέπει να μένει κλειστό εκτός αν ένα δευτερεύον το χρειάζεται πραγματικά.

Στρέψτε τον πελάτη σε αυτήν, ανά σύνδεσμο

Υποθέστε ότι το NetworkManager κατέχει τη σύνδεση και ότι το systemd-resolved είναι ο resolver. Διαβάστε πρώτα την υπάρχουσα πολιτική, ειδικά οποιονδήποτε τομέα δρομολόγησης ρίζας, γιατί μια καταχώρηση ~. θα υπερέχει αυτού που πρόκειται να προσθέσετε.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Η περισπωμένη είναι ο σημαντικός χαρακτήρας. Σημαδεύει τον τομέα ως μόνο-διαδρομή: ονόματα κάτω από το corp.example πηγαίνουν στον διακομιστή DNS αυτής της σύνδεσης, και ο τομέας δεν προσαρτάται ως κατάληξη αναζήτησης σύντομου ονόματος. Χωρίς αυτήν, η πληκτρολόγηση του portal αρχίζει να επιλύει το portal.corp.example, που είναι βολικό για εσάς και απρόσμενο για όλους τους άλλους. Κρατήστε την περισπωμένη μέσα στα εισαγωγικά, γιατί μια χωρίς εισαγωγικά είναι επέκταση κελύφους που περιμένει να δείξει στον κατάλογο σπιτιού σας.

Εφαρμόστε την αλλαγή μέσω του διαχειριστή που κατέχει τη διασύνδεση, μετά επανασυνδέστε τη σύνδεση. Μην ξεκινήσετε δεύτερο στιγμιότυπο wg-quick για την ίδια διασύνδεση· δύο ιδιοκτήτες θα μαλώσουν για τις διαδρομές και ένας από αυτούς θα κερδίσει στην χειρότερη στιγμή.

Επαληθεύστε τη διαδρομή πριν το όνομα

Ρωτήστε το όνομα από τον πελάτη και επιβεβαιώστε και την απάντηση και τον διακομιστή που την παρήγαγε:

resolvectl query portal.corp.example

Αν αυτό επιστρέφει 10.60.0.20, το συμβόλαιο DNS έχει εκπληρωθεί. Αν λήξει, ελέγξτε πρώτα τη διαδρομή προς 10.90.0.1, μετά τον κανόνα του τείχους προστασίας, μετά το allow-query στον διακομιστή. Οι αποτυχίες επίλυσης ονομάτων σε αυτή τη διάταξη είναι σχεδόν πάντα προσβασιμότητα ή ACL, όχι το αρχείο ζώνης. Δουλέψτε προς τα έξω από τον πελάτη, γιατί ο διακομιστής δεν μπορεί να σας πει γιατί ένα ερώτημα δεν έφτασε ποτέ.

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

Τι δεν είναι ακόμη αυτόματο

Οι εφαρμογές με δική τους λογική resolver αγνοούν εντελώς τον resolver του συστήματος, και καμία ποσότητα nmcli δεν το αλλάζει. Οι εγκαταστάσεις που επικυρώνουν DNSSEC χρειάζονται ρητή σχεδίαση άγκυρας εμπιστοσύνης για την ιδιωτική ζώνη· η απάντηση δεν είναι μια γενική οδηγία να απενεργοποιήσετε την επικύρωση. Δοκιμάστε με το ίδιο λογισμικό πελάτη που τρέχουν οι χρήστες σας, όχι με εργαλείο που τυχαίνει να χρησιμοποιεί τον resolver του συστήματος. Το χάσμα ανάμεσα στα δύο είναι ολόκληρη η αναφορά σφάλματος.

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

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

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