Γιατί το δικό του DNS του δρομολογητή παρακάμπτει το τούνελ VPN;

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

Σε ποια ροή ανήκει στην πραγματικότητα η καταγραφή πακέτων

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

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

Ο πρακτικός έλεγχος είναι να παρατηρείτε και τις δύο πλευρές ταυτόχρονα. Στον δρομολογητή, καταγράψτε την υποδοχή του επιλυτή, ρωτήστε την τοπικά και καταγράψτε τη διεπαφή WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

Γιατί η δρομολόγηση πολιτικής δεν βλέπει ποτέ το δεύτερο ερώτημα

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

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

Πού ο επιλυτής του pfSense αποφασίζει τη δική του ανοδική διαδρομή

Το pfSense κάνει τον διαχωρισμό ορατό. Η κίνηση των πελατών μπορεί να δρομολογηθεί με πολιτική μέσω πύλης VPN, ενώ η δική της κίνηση του τείχους προστασίας ακολουθεί τη ρύθμιση εξόδου του επιλυτή και όχι τους κανόνες LAN. Στη διεπαφή ιστού αυτή η ρύθμιση βρίσκεται κάτω από Services > DNS Resolver > Outgoing Network Interfaces, και η τιμή της είναι η λίστα διεπαφών που ο επιλυτής μπορεί να χρησιμοποιεί για ανοδικά ερωτήματα.

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

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

Επιλέξτε τη συμπεριφορά αποτυχίας πριν από τη ρύθμιση

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

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

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

Δοκιμάστε και τις δύο διαδρομές και κρατήστε τα αποτελέσματα χωριστά

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

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Στη συνέχεια ρίξτε το τούνελ και επαναλάβετε και τα δύο ερωτήματα. Οι απορριπτόμενες απαντήσεις σημαίνουν ότι ο επιλυτής κλείνει σε αποτυχία· μια επιτυχημένη απάντηση δείχνει εφεδρικό επιλυτή και τη διαδρομή που χρησιμοποίησε. Συγκρίνετε το με τη σημείωση που γράψατε και με μια καταγραφή στη διεπαφή WAN που ελήφθη το ίδιο λεπτό.

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