Hotspot Pi με Pi-hole και VPN: αναθέστε μια δουλειά σε κάθε υπηρεσία

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

Αναθέστε έναν ιδιοκτήτη ανά λειτουργία

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

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

Γράψτε τους ιδιοκτήτες πριν ενεργοποιήσετε οτιδήποτε άλλο. Ένας σύντομος πίνακας στις σημειώσεις κατασκευής εμποδίζει μια μεταγενέστερη εγκατάσταση να αναλάβει μια λειτουργία που είχε ήδη ιδιοκτήτη.

Διαλέξτε ένα εύρος και κρατήστε το μακριά από το τούνελ

Διαλέξτε το εύρος του hotspot, τη διεύθυνση του Pi μέσα σε αυτό, τη δεξαμενή DHCP και τον resolver που λαμβάνουν οι πελάτες. Κρατήστε αυτό το εύρος ξεχωριστό από το ανάντη LAN και από το εύρος του τούνελ VPN, γιατί τα επικαλυπτόμενα υποδίκτυα μετατρέπουν ένα πρόβλημα δρομολόγησης σε έργο μετάφρασης διευθύνσεων. Ένα εύρος που επικαλύπτει το τούνελ κάνει το Pi τυχαίο δρομολογητή ανάμεσα σε δύο ίδια προθέματα. Γράψτε το εύρος και τη δεξαμενή στη διαμόρφωση του hotspot αντί να τα αφήσετε σε μια προεπιλογή.

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

Αποφασίστε για το IPv6 συνειδητά. Οι αναγγελίες δρομολογητή και το DHCPv6 σε πολλά στησίματα προέρχονται από διαφορετικό βοηθό από το DHCPv4, και αν αφήσετε το IPv6 ενεργό ενώ η πολιτική VPN καλύπτει μόνο IPv4, δίνετε στους πελάτες μια διαδρομή που παρακάμπτει το τούνελ. Είτε σχεδιάστε την πλευρά IPv6 είτε απενεργοποιήστε την στη διεπαφή του hotspot με γραπτή αιτιολογία.

Ποιος απαντά στην πραγματικότητα στη θύρα 53

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

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

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

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

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

Δύο σκέλη DNS, μία πολιτική το καθένα

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

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

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

Αποδείξτε τη διαδρομή και τη συμπεριφορά κατά τη διακοπή

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

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

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

Κρατήστε έναν ιδιοκτήτη για την προώθηση και το NAT και επαληθεύστε τον από πελάτη, όχι από το ίδιο το Pi. Ένα αίτημα που φεύγει επιτυχώς από το Pi μπορεί παρ' όλα αυτά να απορριφθεί στην επιστροφή, και ο πελάτης είναι το μόνο σημείο όπου φαίνεται ολόκληρη η διαδρομή.