DNS του OpenVPN στην πύλη: dnsmasq και εμβέλεια του τείχους προστασίας
Εκτελέστε το dnsmasq στη διεύθυνση της σήραγγας, επιτρέψτε DNS μόνο από τη δεξαμενή πελατών, σπρώξτε τον επιλυτή και μετά δοκιμάστε άμεσα ερωτήματα και την κανονική αναζήτηση της εφαρμογής.
Οι πελάτες στη σήραγγα φτάνουν στην πύλη, και η πύλη φτάνει στον εσωτερικό επιλυτή, άρα το DNS θα έπρεπε να δουλεύει. Δεν δουλεύει, γιατί αυτά είναι δύο διαφορετικές άδειες και μια λειτουργική υπηρεσία DNS είναι τρίτο πράγμα. Ο ακροατής πρέπει να υπάρχει σε διεύθυνση που φτάνουν οι πελάτες, το τείχος προστασίας πρέπει να επιτρέπει ερωτήματα σε αυτή τη διεύθυνση, και πρέπει να ειπωθεί στον πελάτη να τον χρησιμοποιήσει. Το άνοιγμα της σήραγγας και προς τις δύο κατευθύνσεις λύνει τα δύο πρώτα κατά τύχη και αφήνει το τρίτο ημιτελές.
Ο ακροατής είναι τοπική υπηρεσία με δύο κατευθύνσεις
Προς τα μέσα, ένας πελάτης στέλνει ερώτημα στη διεύθυνση σήραγγας της πύλης στη θύρα 53. Προς τα έξω, ο δαίμονας προωθεί αυτό το ερώτημα στον ρυθμισμένο ανάντη διακομιστή του. Και τα δύο μισά πρέπει να δουλεύουν, και αποτυγχάνουν με διαφορετικούς τρόπους.
Ένα timeout που αναφέρει ο πελάτης και ένα timeout που φαίνεται στην πύλη δεν είναι το ίδιο σφάλμα.
Δέστε τη διεύθυνση της σήραγγας, όχι κάθε διεύθυνση
Ένα αφιερωμένο στιγμιότυπο dnsmasq για αυτή τη δουλειά χρειάζεται ρητή διεύθυνση ακρόασης, λειτουργία δέσμευσης που ανέχεται την εμφάνιση της σήραγγας μετά την εκκίνηση και έναν καθαρό ανάντη διακομιστή. Αυτή είναι η μικρότερη εκδοχή που χρησιμοποιώ:
listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53
bind-dynamic δεσμεύει τις επιμέρους διευθύνσεις και τα βγάζει πέρα όταν tun0 εμφανιστεί αργότερα, κάτι που έχει σημασία σε κεντρικό υπολογιστή όπου η υπηρεσία VPN επανεκκινεί. Η καταγραφή του loopback κρατά τα τοπικά εργαλεία σε λειτουργία χωρίς να προσθέτει δημόσιο ακροατή. no-resolv εμποδίζει τον δαίμονα να κληρονομήσει ανάντη διακομιστές από τη ρύθμιση του επιλυτή του κεντρικού υπολογιστή, και no-hosts εμποδίζει αυτό το στιγμιότυπο να δημοσιεύσει το αρχείο hosts της πύλης. Καμία από αυτές τις επιλογές δεν δίνει σε κανέναν άδεια να ερωτά την υπηρεσία.
Ελέγξτε για υπάρχοντα ακροατή στη θύρα 53 πριν ξεκινήσετε δεύτερο δαίμονα, και χρησιμοποιήστε τον ιδιοκτήτη ρύθμισης της διανομής αντί για ένα περιπλανώμενο αρχείο στον λάθος κατάλογο.
Επιτρέψτε είσοδο DNS, όχι διέλευση σήραγγας
Οι κανόνες τείχους προστασίας που το κάνουν να δουλέψει είναι κανόνες τοπικής εισόδου περιορισμένοι στη διεπαφή της σήραγγας, τη δεξαμενή πελατών, τη διεύθυνση της πύλης και τη θύρα 53. Δύο κανόνες, ένας ανά πρωτόκολλο, αρκούν:
sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53
Το DNS τρέχει πάνω από TCP όπως και UDP, οπότε ένας κανόνας μόνο για UDP αφήνει τις μεγάλες απαντήσεις να αποτυγχάνουν με τρόπο που μοιάζει διακοπτόμενος. Αυτά δεν είναι ufw route άδειες, και δεν πρέπει να γίνουν ευρεία άδεια στο tun0. Η σειρά μετράει όσο και το περιεχόμενο: ένας προγενέστερος κανόνας που απορρίπτει κάθε είσοδο από tun0 κερδίζει ακόμη, και μια άδεια κάτω από τελική απόρριψη δεν δημιουργεί τίποτα.
Αν το DNS της πύλης είναι τώρα μέρος του σχεδίου, αναθεωρήστε εκείνη την προγενέστερη πολιτική σκόπιμα και καταγράψτε γιατί.
Το ανάντη μισό είναι ξεχωριστό μονοπάτι
Τα ερωτήματα φεύγουν από την πύλη από τη δική της διεύθυνση προς τον ανάντη επιλυτή, άρα η διαδρομή της πύλης και η πολιτική εξόδου προς αυτόν τον επιλυτή πρέπει να επιτρέπουν την ανταλλαγή. Αυτός είναι διαφορετικός κανόνας από εκείνον που αφήνει τους πελάτες να φτάσουν στον ακροατή, και αποτυγχάνει με διαφορετικό σύμπτωμα.
Μην προσθέσετε απεριόριστη έξοδο σήραγγας για να δουλέψουν οι απαντήσεις· οι απαντήσεις που παρακολουθούνται δεν το χρειάζονται.
Σπρώξτε την επιλογή και μετά ελέγξτε την παράδοση
Ο διακομιστής μπορεί να διαφημίσει τον επιλυτή στους πελάτες με μια σπρωγμένη επιλογή. Αυτή είναι επιλογή, όχι εντολή που το λειτουργικό σύστημα οφείλει να υπακούσει:
push "dhcp-option DNS 10.90.0.1"
Ένας πελάτης Linux από τη γραμμή εντολών μπορεί να χρειάζεται την ενσωμάτωση επιλυτή του διαχειριστή συνδέσεών του, και μια διαχειριζόμενη συσκευή μπορεί να χρειάζεται ενημερωμένο προφίλ διαχείρισης. Επιβεβαιώστε τον ενεργό επιλυτή στον πελάτη μετά τη σύνδεση αντί να υποθέσετε ότι εφαρμόστηκε το σπρώξιμο. Όταν δύο μηχανισμοί προσπαθούν ταυτόχρονα να ορίσουν DNS, παίρνετε έναν αγώνα που παρουσιάζεται ως επίλυση που τρεμοπαίζει.
Στόχος είναι ένας ιδιοκτήτης για τη ρύθμιση επιλυτή του πελάτη, και το σπρώξιμο είναι συνήθως αυτός ο ιδιοκτήτης μόνο όταν η πλατφόρμα του πελάτη συμφωνεί.
Δοκιμάστε αυτό που πραγματικά φτιάξατε
Ρωτήστε ένα ιδιωτικό πλήρως πιστοποιημένο όνομα και ένα επιτρεπόμενο εξωτερικό όνομα απευθείας στη διεύθυνση της σήραγγας, μέσω UDP και TCP. Μετά επαναλάβετε μέσω της συνηθισμένης διαδρομής αναζήτησης της εφαρμογής.
Αν τα άμεσα ερωτήματα δουλεύουν και η εφαρμογή ακόμη αποτυγχάνει, το σφάλμα είναι στην παράδοση και όχι στον διακομιστή:
- Ο πελάτης δεν εφάρμοσε ποτέ τη σπρωγμένη επιλογή.
- Ένας άλλος επιλυτής ορίστηκε αργότερα και κέρδισε τον αγώνα.
- Η εφαρμογή χρησιμοποιεί τη δική της βιβλιοθήκη επιλυτή ή μια αποθηκευμένη απάντηση.
Τελειώστε επιβεβαιώνοντας ότι μια πηγή έξω από την εγκεκριμένη διαδρομή VPN δεν μπορεί να χρησιμοποιήσει καθόλου τον ακροατή. Η επιτυχής επίλυση δεν εξουσιοδοτεί τη διεύθυνση που επέστρεψε, οπότε κρατήστε αυτά τα δύο ερωτήματα χωριστά.