Γιατί τα ιδιωτικά ονόματα DNS αποτυγχάνουν σε πελάτες VPN και πού να ελέγξετε

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

Πριν επεξεργαστείτε οποιοδήποτε προφίλ, επιβεβαιώστε τι κάνει ο πελάτης με το όνομα. Στο Linux, το resolvectl query files.corp.example δείχνει ποια ζεύξη και ποιος επιλύτης παρήγαγαν την απάντηση. Στο Windows, το Resolve-DnsName files.corp.example δείχνει τον διακομιστή που απάντησε και τη διεύθυνση που επέστρεψε.

Διαβάστε την απάντηση πριν αλλάξετε οτιδήποτε

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

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

Διανείμετε τον επιλύτη από μέσα από το τούνελ

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

OpenVPN ανήκει στην πρώτη ομάδα. Στον διακομιστή, το push "dhcp-option DNS 10.8.0.53" και το push "dhcp-option DOMAIN corp.example" ταξιδεύουν στο κανάλι ελέγχου, αλλά μόνο αν η ρύθμιση του πελάτη έχει ακόμη ενεργό το pull. Ένας χειροκίνητα επεξεργασμένος πελάτης που φέρει pull-filter ignore "dhcp-option" δεν θα τα δει ποτέ, και αυτή η μία γραμμή εξηγεί εντυπωσιακά πολλές περιπτώσεις του «ο διακομιστής το σπρώχνει αλλά ο φορητός μου διαφωνεί».

Το WireGuard ανήκει στη δεύτερη ομάδα, γιατί το πρωτόκολλο δεν έχει καθόλου διαπραγμάτευση επιλογών. Ο επιλύτης και το πεδίο αναζήτησης μπαίνουν στο δικό του μπλοκ [Interface] του πελάτη ως DNS = 10.8.0.53, corp.example. Το wg-quick το εφαρμόζει μέσω resolvconf ή systemd-resolved, και στο Windows ο επίσημος πελάτης εγκαθιστά κανόνες NRPT που υπάρχουν μόνο όσο το τούνελ είναι πάνω: το Get-DnsClientNrptPolicy τους απαριθμεί, κάτι που το κάνει γρήγορο τρόπο να δείτε αν ο πελάτης εφάρμοσε ποτέ το αρχείο σας.

Το IPsec/IKEv2 βρίσκεται στη μέση. Το πρόσθετο attr του strongSwan μπορεί να επιστρέψει διακομιστή DNS από δεξαμενή, και ένας πελάτης Windows συνήθως το δέχεται, αλλά ένα προφίλ που καρφώνει τον δικό του διακομιστή ονομάτων κερδίζει ό,τι κι αν προσφέρει η πύλη. Σε πελάτη Linux το ισοδύναμο χειροκίνητο βήμα είναι το resolvectl dns wg0 10.8.0.53 και μετά το resolvectl domain wg0 '~corp.example'· και τα δύο εξαφανίζονται μαζί με τη διεπαφή, που είναι ακριβώς ό,τι θέλετε για ρύθμιση περιορισμένη στο τούνελ.

Περιορίστε το επίθημα αντί να καταπίνετε κάθε ερώτημα

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

Στείλτε προς τα μέσα μόνο το ιδιωτικό επίθημα. Στο systemd-resolved, ένα πεδίο που αρχίζει με ~ είναι μόνο για δρομολόγηση, άρα το ~corp.example σημαίνει ότι τα ερωτήματα κάτω από αυτό το επίθημα πηγαίνουν στους διακομιστές εκείνης της ζεύξης ενώ όλα τα άλλα συνεχίζουν να χρησιμοποιούν το φυσικό δίκτυο. Το Windows κάνει το ίδιο με κανόνες NRPT περιορισμένους σε χώρο ονομάτων, και το macOS με συμπληρωματικό αρχείο επιλύτη κάτω από το /etc/resolver/.

Τα ονόματα multicast αξίζουν τη δική τους απάντηση. Τα ονόματα .local είναι link-local εξ ορισμού (RFC 6762) και μια διεπαφή tun σημείου-προς-σημείο δεν μεταφέρει αυτή την ομάδα multicast, άρα η προσθήκη δημόσιου επιλύτη δεν θα τα δημοσιεύσει και η ερώτηση σε εσωτερικό επιλύτη unicast επιστρέφει NXDOMAIN. Ένας ανακλαστήρας όπως το avahi σε λειτουργία ανάκλασης μπορεί να γεφυρώσει δύο τμήματα, αλλά αυτό είναι απόφαση στην πλευρά του διακομιστή που κανένας πελάτης δεν μπορεί να ζητήσει. Αν ένας εκτυπωτής ή ένα NAS πρέπει να είναι προσβάσιμο με όνομα, δώστε του εγγραφή A στη ζώνη σας.

Αποδείξτε ότι η απάντηση μπορεί να επιστρέψει

Μια σωστή απάντηση που δείχνει σε μη προσβάσιμη διεύθυνση μοιάζει ακριβώς με πρόβλημα επιλύτη μέχρι να ελέγξετε τη διαδρομή. Ρωτήστε τον πυρήνα πού θα πάει η απάντηση: το ip route get 10.20.5.20 ονομάζει τη διεπαφή και, πιο χρήσιμα, τη διεύθυνση προέλευσης που θα χρησιμοποιήσει.

Παρατηρήστε την ίδια τη διεύθυνση του επιλύτη. Ένας πελάτης με DNS = 10.8.0.53 δίπλα σε AllowedIPs = 10.20.0.0/16 στέλνει τα ερωτήματά του έξω από τη φυσική κάρτα δικτύου, όπου πεθαίνουν σιωπηλά, γιατί ο επιλύτης δεν βρίσκεται μέσα σε κανένα πρόθεμα που διεκδικεί το τούνελ. Αυτή η αναντιστοιχία είναι η συχνότερη βλάβη με μία αιτία σε όλο αυτό το πεδίο, και μένει αόρατη αν δεν συγκρίνετε τη ρύθμιση DNS με τα επιτρεπόμενα προθέματα γραμμή προς γραμμή.

Επικαλυπτόμενα εύρη προκαλούν την αντίθετη βλάβη. Η απάντηση είναι σωστή, η διαδρομή υπάρχει, και δείχνει σε λάθος κεντρικό υπολογιστή, γιατί το 192.168.0.0/24 στο σπίτι είναι πιο συγκεκριμένο από τη διαδρομή του τούνελ στο ίδιο εύρος. Επαναριθμήστε τη μία πλευρά ή σπρώξτε στενότερη διαδρομή, και μετά επιβεβαιώστε το τείχος προστασίας και την επιστροφή του κεντρικού υπολογιστή της υπηρεσίας· οι σημειώσεις του strongSwan για προώθηση καλύπτουν την πλευρά sysctl αυτής της διαδρομής.

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

Επαναλάβετε τη δοκιμή από τον πελάτη, όχι από την πύλη

Δοκιμάστε μέσα στην εφαρμογή για την οποία παραπονιέται ο χρήστης, γιατί μια αναζήτηση από τη γραμμή εντολών δεν αποδεικνύει ότι το πρόγραμμα περιήγησης ακολουθεί την ίδια διαδρομή. Το ασφαλές DNS του Chrome και το network.trr.mode του Firefox μπορούν να παρακάμψουν εντελώς τον επιλύτη του συστήματος, και όταν το κάνουν, ένα ιδιωτικό όνομα είτε αποτυγχάνει είτε διαρρέει σε δημόσιο επιλύτη. Η σύγκριση του resolvectl query με ένα χειροκίνητο dig @10.8.0.53 files.corp.example σας λέει ποιο από τα δύο συνέβη.

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

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