Η διαχωρισμένη σήραγγα εξαιρεί τον περιηγητή, όχι τα ερωτήματα DNS του

Ο περιηγητής εξαιρείται από τη σήραγγα, η σελίδα δημόσιας IP επιβεβαιώνει ότι η κίνησή του βγαίνει από τη σύνδεση του σπιτιού, και το εσωτερικό wiki ακόμη δεν ανοίγει. Η ανάλυση ονομάτων πήγε αλλού, και αυτό το αλλού είναι συνήθως ο resolver που ρύθμισε το VPN. Η διαδρομή δεδομένων και η διαδρομή του resolver είναι ξεχωριστές αποφάσεις στα περισσότερα σχέδια split tunnel. Ελέγξτε ποια χρησιμοποίησε πραγματικά ο περιηγητής πριν χαρακτηρίσετε την εξαίρεση χαλασμένη.

Η διαδρομή δεδομένων και η διαδρομή resolver χωρίζονται

Μια εξαίρεση αφαιρεί τα πακέτα μιας εφαρμογής από τη σήραγγα, που είναι απόφαση δρομολόγησης και τείχους προστασίας στη διαδρομή δεδομένων. Η ανάλυση ονομάτων είναι άλλη αναζήτηση: μια διεργασία ρωτά τον resolver του συστήματος, και εκείνος ο resolver αποφασίζει ποιος διακομιστής λαμβάνει την ερώτηση.

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

Βρείτε ποια διεργασία κάνει την ερώτηση

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Διαβάστε την ενεργή διαμόρφωση πριν δοκιμάσετε: ποιοι σύνδεσμοι μεταφέρουν διακομιστές DNS, ποιους χώρους ονομάτων διεκδικούν, και αν μια πολιτική ανά όνομα υπερισχύει της προεπιλογής. Στο Linux το split DNS χρησιμοποιεί τομείς δρομολόγησης· στο Windows ο πίνακας πολιτικής ανάλυσης ονομάτων κάνει την ίδια δουλειά για χώρους ονομάτων. Κανένα από τα δύο δεν φαίνεται από σελίδα δοκιμής διαρροής.

Αποφασίστε ποιος resolver βλέπει ποιο όνομα

Γράψτε την επιδιωκόμενη αντιστοίχιση πριν αλλάξετε οτιδήποτε: εσωτερικά ονόματα στον εταιρικό resolver, δημόσια ονόματα στην υπηρεσία που επιτρέπει η πολιτική, και εξαιρέσεις με υπεύθυνο. Χωρίς αυτή τη λίστα, κάθε ετικέτα της δοκιμής διαρροής γίνεται πολιτική διαφωνία που κανείς δεν μπορεί να κλείσει.

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

Μην ξαναγράφετε κάθε πεδίο DNS για να γίνει πράσινη μία ετικέτα δοκιμής. Η ετικέτα περιγράφει ένα ερώτημα από μία διεργασία σε μία στιγμή.

Επαληθεύστε ερώτημα και σύνδεση χωριστά

Δοκιμάστε τις δύο διαδρομές ανεξάρτητα. Η δοκιμή σύνδεσης δείχνει τη διαδρομή δεδομένων, και η δοκιμή resolver δείχνει ποιος έλαβε το όνομα.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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