Γιατί το Pi-hole v6 αγνοεί τα ερωτήματα DNS από πελάτες WireGuard

Το Pi-hole v6 δέχεται ένα ερώτημα DNS στη θύρα 53 και μετά αποφασίζει αν επιτρέπεται να απαντηθεί το πακέτο που έφτασε. Σε έναν κεντρικό υπολογιστή WireGuard αυτή η δεύτερη απόφαση είναι συνήθως ο λόγος που ένας πελάτης παίρνει χρονικό όριο ενώ ο επιλυτής φαίνεται υγιής από το LAN. Η θύρα είναι ανοιχτή, το FTL τρέχει, και όμως τίποτα δεν επιστρέφει από το 10.90.0.1. Τρία πράγματα αλληλεπιδρούν πριν φύγει μια απάντηση: dns.interface, dns.listeningMode και το τείχος προστασίας μπροστά και από τα δύο.

Το socket ακρόασης δεν αποφασίζει ποιος παίρνει απάντηση

Το FTL ανοίγει ακροατές UDP και TCP στη θύρα 53. Στην προεπιλεγμένη διαμόρφωση το socket είναι συχνά wildcard, οπότε ss -lunp | grep :53 δείχνει 0.0.0.0:53 και [::]:53 ανεξάρτητα από το αν εξυπηρετούνται πελάτες VPN. Ένα socket wildcard δέχεται το πακέτο και μετά το FTL εφαρμόζει τους κανόνες διεπαφής και πηγής πριν απαντήσει. Γι’ αυτό η φράση «η θύρα ακούει» αποδεικνύει ελάχιστα για έναν πελάτη σήραγγας.

Διαβάστε τη διαμόρφωση που εκτελείται και όχι το αρχείο που νομίζετε ότι είναι ενεργό. pihole-FTL --config dns.interface και pihole-FTL --config dns.listeningMode εκτυπώνουν τις πραγματικές τιμές και μπορεί να διαφέρουν από το αρχείο του κεντρικού υπολογιστή όταν ένα κοντέινερ, μια μεταβλητή περιβάλλοντος ή ένας διαχειριστής ανάπτυξης κατέχει τη ρύθμιση. Ο Οδηγός διαμόρφωσης του Pi-hole FTL απαριθμεί τις λειτουργίες και ποια από αυτές βασίζεται στη διεπαφή.

Το LOCAL ρωτά ποιο υποδίκτυο, το SINGLE ρωτά ποια διεπαφή

Το LOCAL, η προεπιλογή, απαντά σε ερωτήματα των οποίων η διεύθυνση πηγής ανήκει σε υποδίκτυο που έχει ρυθμιστεί σε μία από τις διεπαφές του κεντρικού υπολογιστή. Ένα απλό wg0 με 10.90.0.1/24 περνά αυτή τη δοκιμή, γιατί ο πελάτης στο 10.90.0.2 βρίσκεται μέσα στο υποδίκτυο της σήραγγας. Ένας πελάτης με δρομολόγηση στην άλλη πλευρά ενός peer, ή ένας κρυμμένος πίσω από NAT σε διαφορετικό πρόθεμα, δεν την περνά παρόλο που το πακέτο έφτασε στο wg0, και κανένα ερώτημα δεν εμφανίζεται στο αρχείο καταγραφής.

Το SINGLE αλλάζει την ερώτηση. Δέχεται ερωτήματα που φτάνουν στη διεπαφή που ονομάζεται στο dns.interface, με το loopback να περιλαμβάνεται, και αγνοεί το υποδίκτυο πηγής. Αυτή είναι η λειτουργία που επιβιώνει σε τοπολογία VPN με αλυσίδα ή δρομολόγηση. Ορίστε και τα δύο κλειδιά μαζί, γιατί μια λειτουργία χωρίς ονομασμένη διεπαφή δεν είναι πλήρης οδηγία:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

Το BIND αλλάζει το socket, και αυτό έχει κόστος

Το BIND δεν φιλτράρει ένα socket wildcard· δεσμεύει τη θύρα 53 μόνο σε διευθύνσεις που υπάρχουν στην ονομασμένη διεπαφή, οπότε ο πυρήνας απορρίπτει πακέτα που φτάνουν αλλού. Είναι αυστηρότερο από το SINGLE και δεν είναι συνώνυμο του. Το κόστος εμφανίζεται στην εκκίνηση: αν το wg0 δεν είναι ενεργό όταν ξεκινά το FTL, μπορεί να μην υπάρχει διεύθυνση για δέσμευση και ο επιλυτής μπορεί να τρέχει χωρίς ακροατή μέχρι να εμφανιστεί η διεπαφή και να επανεκκινήσει το FTL.

Επιλέξτε BIND όταν ελέγχετε τη σειρά εκκίνησης, για παράδειγμα μια μονάδα systemd ταξινομημένη μετά τη διεπαφή WireGuard, και όταν θέλετε ο πυρήνας να απορρίπτει τα περιπλανώμενα πακέτα πριν τα δει το FTL. Επιλέξτε SINGLE όταν η σήραγγα έρχεται και φεύγει, ή όταν η διεπαφή δημιουργείται από εργαλείο που ξεκινά μετά το FTL.

Το τείχος προστασίας είναι η δεύτερη πύλη

Μια σωστή λειτουργία FTL αποτυγχάνει ακόμα αν το τείχος του κεντρικού υπολογιστή απορρίπτει τη θύρα 53 στο wg0. Επιτρέψτε το εύρος πηγών VPN και για τα δύο πρωτόκολλα και κρατήστε την πλευρά του διαδικτύου κλειστή. Στο nftables, με την υπάρχουσα αλυσίδα input στον πίνακα inet filter, οι κανόνες μοιάζουν έτσι:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Προσθέστε αντίστοιχους κανόνες IPv6 αν η σήραγγα μεταφέρει IPv6, και βάλτε τους πριν από την πολιτική απόρριψης της αλυσίδας. Αν ο κεντρικός υπολογιστής χρησιμοποιεί ufw ή firewalld, εκφράστε την ίδια αντιστοίχιση σε εκείνον τον διαχειριστή αντί να αναμιγνύετε εργαλεία. Μη προωθείτε τη θύρα 53 από τον δρομολογητή του διαδικτύου· οι πελάτες πρέπει να φτάνουν στη διεύθυνση VPN του επιλυτή μέσω της σήραγγας.

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

Επαληθεύστε την απάντηση και την άρνηση

Από έναν πελάτη VPN, ρωτήστε τη διεύθυνση του επιλυτή και με τα δύο πρωτόκολλα: dig @10.90.0.1 example.com και dig +tcp @10.90.0.1 example.com. Μετά ελέγξτε το αρχείο καταγραφής ερωτημάτων στη διεπαφή διαχείρισης για να επιβεβαιώσετε ότι το FTL κατέγραψε το ερώτημα. Ένα χρονικό όριο πελάτη χωρίς εγγραφή στο αρχείο δείχνει το τείχος προστασίας ή το φίλτρο διεπαφής· μια εγγραφή χωρίς απάντηση δείχνει την επίλυση στα ανάντη.

Δοκιμάστε την αρνητική διαδρομή από κεντρικό υπολογιστή εκτός VPN. dig @10.90.0.1 example.com θα πρέπει να λήξει, και ss -lunp στον επιλυτή δεν θα πρέπει να δείχνει τη θύρα 53 δεσμευμένη σε δημόσια διεύθυνση. Επανεκκινήστε την υπηρεσία μία φορά, μετά επανεκκινήστε τον κεντρικό υπολογιστή και επιβεβαιώστε ότι ο επιλυτής απαντά ακόμα όταν το wg0 εμφανιστεί ξανά. Ένα ερώτημα που λειτουργεί μόνο μέχρι την επόμενη επανεκκίνηση δεν είναι ολοκληρωμένη αλλαγή.