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

Πάρτε το παράδειγμα εξουσιοδοτημένων πελατών στο 10.77.0.0/24 που φτάνουν μέσω wg0, ρωτούν τη διαφημιζόμενη διεύθυνση 10.77.0.1 και χρειάζονται έναν resolver στο 203.0.113.53. Η ανάντη διεύθυνση είναι θέση κράτησης για τεκμηρίωση και όχι υπηρεσία σε λειτουργία.

Η ανακατεύθυνση ενός ερωτήματος αλλάζει μόνο τον προορισμό του

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

Και τα δύο κανάλια DNS χρειάζονται αντίστοιχους κανόνες, γιατί ένας πελάτης επιστρέφει στο TCP όταν μια απάντηση περικόπτεται.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Η διαδρομή απάντησης είναι ξεχωριστή απόφαση

Δύο διατάξεις αφήνουν την απάντηση να επιστρέψει, και η έγκαιρη επιλογή μιας γλιτώνει μια συνεδρία αποσφαλμάτωσης. Είτε ο ανάντη resolver έχει διαδρομή πίσω προς το 10.77.0.0/24 μέσω αυτής της πύλης, είτε η πύλη μεταφράζει την πηγή στην έξοδο ώστε η απάντηση να φτάσει σε διεύθυνση που το ανάντη γνωρίζει ήδη. Και τα δύο δουλεύουν· μόνο το ένα ταιριάζει με τον έλεγχο που έχετε πάνω στο ανάντη.

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

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

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

Γράψτε τους κανόνες στενότερους απ’ ό,τι φαίνεται η εργασία

Η άδεια προώθησης ανήκει στο ίδιο πεδίο. Επιτρέψτε τη ροή από τον πελάτη στον resolver και την επιστρεφόμενη κίνηση που το conntrack ήδη αναγνωρίζει, αντί να δέχεστε κάθε σύνδεση DNAT στο μηχάνημα. Μια γενική αποδοχή εξουσιοδοτεί και προωθήσεις θυρών που δεν έχουν καμία σχέση με το DNS.

Ο δικός του resolver της πύλης είναι διαφορετικό μονοπάτι κώδικα. Ένα ερώτημα που εκδίδεται τοπικά περνά από το OUTPUT, οπότε η δοκιμή από το κέλυφος της πύλης δεν ασκεί ούτε τον κανόνα PREROUTING ούτε την πολιτική προώθησης. Γι’ αυτό μια τοπική δοκιμή μπορεί να περάσει ενώ κάθε πελάτης αποτυγχάνει, και το αντίστροφο είναι εξίσου συχνό.

Τίποτε εδώ δεν καλύπτει DNS over HTTPS στη θύρα 443 ή DNS over TLS στη θύρα 853, και τίποτε δεν καλύπτει το IPv6. Ένας πελάτης με ρυθμισμένο resolver IPv6 θα αγνοήσει ευχαρίστως όλη τη διάταξη.

Τι αποδεικνύει ένα νέο ερώτημα

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

Επιβεβαιώστε ότι ο resolver γνωρίζει τα ονόματα που περιμένετε πριν ανακατευθύνετε οτιδήποτε. Το Μια αντικατάσταση που απαντά σε δημόσια ονόματα αλλά όχι στη δική σας ιδιωτική ζώνη μετατρέπει μια λειτουργική αναζήτηση σε NXDOMAIN που μοιάζει με σπασμένο τούνελ. Δοκιμάστε τον resolver απευθείας, από την πύλη, πριν εμπλακεί η διαδρομή του πελάτη. Και το αναφορά επεκτάσεων του iptables τεκμηριώνει τη σημασιολογία DNAT και masquerade από την οποία εξαρτώνται αυτοί οι κανόνες.

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