Γιατί τα ερωτήματα του dnsmasq διαφεύγουν από το VPN μετά από ανακατεύθυνση DNS

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

Το σημάδι δεν ταξιδεύει με το ερώτημα

Τα σημάδια πακέτων ζουν σε μια εγγραφή conntrack και στο πακέτο εν πτήσει. Ένας κανόνας REDIRECT τερματίζει αυτή την πτήση: το φορτίο παραδίδεται σε τοπική υποδοχή και η αρχική εγγραφή έχει κάνει τη δουλειά της. Αυτό που φεύγει μετά από τον δρομολογητή είναι μια νέα υποδοχή που δημιούργησε η διεργασία του resolver, με πηγή τη διεύθυνση του ίδιου του δρομολογητή.

Γι’ αυτό μια διαδρομή πολιτικής βασισμένη στη διεύθυνση του πελάτη LAN δεν ταιριάζει ποτέ με το ερώτημα προς τα πάνω. Η νέα υποδοχή ανήκει στο dnsmasq και όχι στον πελάτη, και ο πυρήνας αξιολογεί τη διαδρομή για την κίνηση του ίδιου του δρομολογητή. Κανόνες πηγής, κανόνες διεπαφής και κανόνες σημάτων βλέπουν όλοι διαφορετική πλειάδα. Το να υποθέτει κανείς ότι το σημάδι διαδίδεται είναι το συνηθέστερο λάθος σε αυτή τη διάταξη και είναι αόρατο σε σύλληψη από την πλευρά του πελάτη.

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

Πού η προώθηση γίνεται τοπική επίλυση

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

Κοιτάξτε και τα δύο πρωτόκολλα. Ένας resolver προσβάσιμος μέσω UDP και TCP θα δοκιμαστεί και στα δύο, και ένα σύνολο κανόνων που καλύπτει μόνο UDP αφήνει μια ήσυχη τρύπα για μεγάλες απαντήσεις. Οι κανόνες που παράγει ο ίδιος ο διαχειριστής ρυθμίσεων του δρομολογητή μετράνε επίσης, και η επεξεργασία ενός παραγόμενου αρχείου συνήθως χάνει από την επόμενη επαναφόρτωση.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

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

Δώστε στον resolver τη δική του πολιτική εξόδου

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

server=/corp.example/10.30.0.53@tun_work
log-queries

Ο τομέας, η διεύθυνση και η διεπαφή παραπάνω είναι θέσεις για τις δικές σας τιμές. Η επιλογή τομέα και ο έλεγχος εξόδου παραμένουν ξεχωριστές αποφάσεις: η διαδρομή πρέπει να υπάρχει, η διεύθυνση πηγής πρέπει να επιτρέπεται από τον resolver προς τα πάνω και το τείχος προστασίας πρέπει να επιτρέπει την απάντηση. Η καθοδήγηση μόνο μέσω διεπαφής δεν είναι fail-closed, γιατί μια σήραγγα που εξαφανίζεται μπορεί να αφήσει τον resolver να πέσει σε άλλη διαδρομή. Κρατήστε κάθε δημόσια εφεδρική διαδρομή μακριά από χώρο ονομάτων που πρέπει να μείνει ιδιωτικός.

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

Τι δεν μπορεί να διατηρήσει μια κοινή κρυφή μνήμη

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

Μια αποθηκευμένη απάντηση δεν είναι επίσης απόδειξη για τη νέα διαδρομή. Η απάντηση μπορεί να έρθει από τη μνήμη ενώ η διαδρομή προς τα πάνω μένει σπασμένη.

Οι κανόνες της θύρας 53 δεν λένε τίποτα για εφαρμογές που μιλούν DNS μέσω HTTPS ή μέσω TLS. Αυτά τα ερωτήματα δεν φτάνουν ποτέ στην ανακατεύθυνση, οπότε μια πολιτική χτισμένη μόνο στη θύρα 53 περιγράφει ένα υποσύνολο της κίνησης και θα πρέπει να τεκμηριώνεται ως υποσύνολο.

Επαληθεύστε τη δεύτερη συνομιλία, όχι την πρώτη

Δοκιμάστε με ένα όνομα που ελέγχετε και παρακολουθήστε και τις δύο πλευρές. Μια σύλληψη από την πλευρά του πελάτη αποδεικνύει ότι το ερώτημα έφυγε από το LAN· μόνο η πλευρά του δρομολογητή αποδεικνύει πού πήγε μετά.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

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