Το Pi-hole δεν μπλοκάρει τις διαφημίσεις μετά τη σύνδεση VPN: πέντε έλεγχοι

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

1. Διαβάστε τον resolver που χρησιμοποιεί πραγματικά ο πελάτης

Ρωτήστε τον πελάτη, όχι τον δρομολογητή. Στο Linux το resolvectl status εκτυπώνει τους διακομιστές DNS ανά ζεύξη και ποια ζεύξη κερδίζει· το /etc/resolv.conf από μόνο του είναι συνήθως ένα stub που δείχνει στο 127.0.0.53. Στα Windows το ipconfig /all απαριθμεί τους διακομιστές που παρέχει το DHCP ανά προσαρμογέα, και στο macOS το scutil --dns δείχνει το ίδιο ανά πεδίο. Αν η απάντηση δεν είναι η διεύθυνση του Pi-hole, έχετε πρόβλημα ανάθεσης και το βήμα 2 είναι εκεί όπου βρίσκεται.

Δύο πράγματα νικούν τον resolver του συστήματος ακόμη και όταν είναι σωστά ρυθμισμένος. Τα προγράμματα περιήγησης με δικό τους ασφαλές DNS (η επιλογή “Use secure DNS” του Chrome, το network.trr.mode του Firefox) στέλνουν ερωτήματα μέσω HTTPS σε δημόσιο resolver και δεν ανοίγουν ποτέ τη θύρα 53. Και ένας πελάτης VPN στον ίδιο τον πελάτη μπορεί να εγκαταστήσει διακομιστή DNS στη διεπαφή σήραγγας με πεδίο δρομολόγησης ~., γεγονός που κάνει αυτή τη ζεύξη έγκυρη για κάθε όνομα.

Δοκιμάστε τη διαδρομή που ακολουθούν οι εφαρμογές, όχι τη διαδρομή που ακολουθεί ένα εργαλείο αποσφαλμάτωσης. Το resolvectl query example.com δείχνει ποια ζεύξη απάντησε, και το getent hosts example.com περνά από την ίδια διαδρομή NSS με μια εφαρμογή· στο macOS το dscacheutil -q host -a name example.com διαβάζει τους resolvers ανά πεδίο που απαριθμεί το scutil --dns. Ένα γυμνό dig δεν το κάνει αυτό: διαβάζει το /etc/resolv.conf και παραλείπει την επιλογή ανά ζεύξη, άρα μπορεί να απαντήσει από το Pi-hole ενώ κάθε εφαρμογή χρησιμοποιεί τον προωθημένο resolver, και αυτή είναι ακριβώς η αποτυχία για την οποία υπάρχει αυτή η λίστα. Κρατήστε το dig @192.168.1.53 για τη δοκιμή ενός συγκεκριμένου διακομιστή.

2. Επιβεβαιώστε ποιος μοιράζει την απάντηση

Η ανάθεση προέρχεται από ό,τι απαντά στο DHCP. Στο dnsmasq αυτό είναι μία γραμμή, dhcp-option=6,192.168.1.53· στη διεπαφή ιστού του δρομολογητή είναι το πεδίο DNS στην ενότητα DHCP του LAN. Οι πελάτες πρέπει να ανανεώσουν πριν το δουν. Μια συσκευή που είναι ενεργή εδώ και ημέρες κρατά ακόμη την παλιά μίσθωση, και μια συσκευή με χειροκίνητα πληκτρολογημένο resolver την κρατά για πάντα. Ανανεώστε σε πελάτη δοκιμής αντί να υποθέσετε τη διάδοση.

Το IPv6 είναι το μισό που χάνεται. Οι αναγγελίες δρομολογητή μπορούν να μεταφέρουν τον δικό τους διακομιστή DNS (RDNSS), και στο OpenWrt αυτό είναι η επιλογή ra_dns του odhcpd· ένας πελάτης που προτιμά το IPv6 χρησιμοποιεί αυτόν τον διακομιστή ενώ η επιλογή DHCPv4 που μόλις ορίσατε μένει ανενεργή. Αν δεν είστε έτοιμοι να σερβίρετε DNS μέσω IPv6, καθαρίστε μόνο την αναγγελία DNS: ra_dns στο odhcpd ή την επιλογή RDNSS σε ό,τι απαντά στις αναγγελίες δρομολογητή. Η απενεργοποίηση ολόκληρης της αναγγελίας αφαιρεί επίσης τη διευθυνσιοδότηση IPv6 από το LAN, που είναι πολύ μεγαλύτερη αλλαγή από αυτή που σκοπεύατε, ενώ ο καθαρισμός μόνο της επιλογής DNS αφήνει τη διευθυνσιοδότηση άθικτη και κάνει το απόν RDNSS ορατό σε καταγραφή πακέτων.

3. Αποδείξτε ότι το ερώτημα φτάνει στο Pi-hole

Ένα ερώτημα από το Pi δεν αποδεικνύει τίποτα για τη διαδρομή δικτύου. Εκτελέστε το από τον πελάτη και διαβάστε τον κωδικό απόκρισης:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Ένα χρονικό όριο δείχνει φιλτράρισμα ή διαδρομή· το REFUSED δείχνει κανόνα πρόσβασης· το SERVFAIL δείχνει τον ανάντη resolver πίσω από το Pi-hole· μια σωστή απάντηση που δεν εμφανίζεται ποτέ στο αρχείο ερωτημάτων σημαίνει ότι ο πελάτης ρώτησε κάτι άλλο. Ελέγξτε UDP και TCP 53, γιατί οι μεγάλες απαντήσεις και ορισμένοι resolvers πέφτουν πίσω σε TCP, και δημοσιεύστε και τα δύο όταν το Pi-hole τρέχει σε container. Μια αντιστοίχιση που καλύπτει μόνο UDP παράγει διακοπτόμενες αποτυχίες που μοιάζουν με απώλεια πακέτων.

Έπειτα η λειτουργία ακρόασης του Pi-hole αποφασίζει αν απαντά καθόλου. Στη λειτουργία μόνο τοπικά το dnsmasq αγνοεί ερωτήματα από πηγές που δεν βρίσκονται σε άμεσα συνδεδεμένο υποδίκτυο, και έτσι ακριβώς μοιάζει ένας πελάτης πίσω από άλλον δρομολογητή ή ένας που φτάνει μέσω σήραγγας: ο πελάτης λήγει και το ερώτημα δεν φτάνει ποτέ στο αρχείο. Ένα ερώτημα που εμφανίζεται ως REFUSED απορρίφθηκε από λίστα πρόσβασης ή κανόνα τείχους προστασίας. Η άδεια σε όλες τις προελεύσεις είναι η συνηθισμένη διόρθωση, μαζί με έναν κανόνα τείχους προστασίας που περιορίζει τη θύρα 53 στα δικά σας υποδίκτυα.

4. Ελέγξτε αν η σήραγγα αντικατέστησε ή κατάπιε την απάντηση

Αυτή είναι η περίπτωση όπου κρύβονται και τα δύο συμπτώματα. Όταν ο δρομολογητής είναι ο ίδιος πελάτης VPN, μια προωθημένη επιλογή DNS μπορεί να υπερισχύσει της ρύθμισης LAN τη στιγμή που σηκώνεται η σήραγγα: οι διακομιστές OpenVPN προωθούν dhcp-option DNS, και τα προφίλ WireGuard φέρουν τη δική τους καταχώριση DNS. Διαβάστε τον πραγματικό resolver του δρομολογητή με τη σήραγγα ενεργή, όχι πριν, και αγνοήστε ό,τι ισχυρίζεται η σελίδα του LAN.

Η άλλη βλάβη είναι προσβασιμότητα και όχι αντικατάσταση. Αν τα επιτρεπόμενα προθέματα της σήραγγας περιλαμβάνουν το υποδίκτυο LAN σας, ο δρομολογητής έχει διαδρομή που στέλνει τα ερωτήματα για το 192.168.1.53 μέσα στη σήραγγα, και η απέναντι πλευρά δεν έχει διαδρομή επιστροφής: τα ερωτήματα λήγουν μολονότι η σήραγγα είναι υγιής. Το αντίστροφο συμβαίνει όταν το Pi-hole βρίσκεται σε υποδίκτυο που η σήραγγα δεν μεταφέρει. Συγκρίνετε τη διεύθυνση με τα επιτρεπόμενα προθέματα της σήραγγας και τον πίνακα δρομολόγησης του δρομολογητή πριν αγγίξετε ξανά το DNS.

Επιλέξτε μία διόρθωση αντί για τις δύο. Είτε κρατήστε τη σήραγγα μακριά από το DNS — με pull-filter ignore “dhcp-option DNS” στο OpenVPN και χωρίς πρόθεμα LAN στο AllowedIPs στο WireGuard — είτε δεχτείτε τον προωθημένο resolver και εγκαταλείψτε το τοπικό φιλτράρισμα για τους πελάτες πίσω από αυτόν τον δρομολογητή. Όποιο κι αν επιλέξετε, γράψτε το δίπλα στο προφίλ, γιατί το επόμενο άτομο που θα το επεξεργαστεί θα αντιστρέψει αλλιώς την απόφαση κατά λάθος.

5. Επαναλάβετε τη δοκιμή μετά από επανασύνδεση

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

Αφήστε μια δευτερεύουσα διαδρομή resolver που δεν εξαρτάται από τη σήραγγα, ώστε μια διακοπή του Pi-hole να υποβαθμίζεται σε αφιλτράριστη περιήγηση αντί σε καθόλου περιήγηση. Κρατήστε τις προηγούμενες τιμές DHCP και resolver μέχρι η δοκιμή να περάσει δύο φορές· μια αλλαγή που σπάει το διαδίκτυο του νοικοκυριού στο δείπνο είναι πολύ δυσκολότερο να αποσφαλματωθεί από μία που μπορείτε να αναιρέσετε σε ένα λεπτό.