Το StrongSwan στέλνει μια διεύθυνση DNS που το Mac δεν μπορεί να φτάσει

Όλα λειτουργούν μέχρι κάποιος να ανοίξει ένα MacBook. Το tunnel σηκώνεται, οι εσωτερικοί hosts απαντούν με διεύθυνση και η επίλυση ονομάτων πεθαίνει. Στο iPhone το ίδιο προφίλ συμπεριφέρεται με τον ίδιο τρόπο, ενώ οι πελάτες Windows και Linux είναι εντάξει. Συνήθως ο ένοχος είναι το χαρακτηριστικό DNS που αποστέλλεται: ο διακομιστής μοιράζει τη δική του δημόσια διεύθυνση διεπαφής και ο πελάτης IKEv2 της Apple δεν στέλνει εκεί ερωτήματα μέσω του tunnel. Μετακινήστε τον resolver μέσα στο pool και το σύμπτωμα εξαφανίζεται χωρίς να αγγίξετε τον πελάτη.

Το σύμπτωμα δείχνει τη διεύθυνση που αποστέλλεται

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

Η δημόσια διεύθυνση είναι η συνηθισμένη επιλογή, γιατί είναι η μόνη που γνωρίζει ήδη ο διαχειριστής. Είναι επίσης η μόνη διεύθυνση που είναι εγγυημένα έξω από το δικό του πρόθεμα του tunnel, και ακριβώς αυτή η ιδιότητα σπάει τους πελάτες της Apple.

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

Κόψτε τον resolver έξω από το εύρος μίσθωσης

Δώστε στο tunnel ένα σχέδιο διευθύνσεων όπου ο resolver είναι μέλος του δικού του υποδικτύου του pool, και μετά δεσμεύστε αυτή τη διεύθυνση ώστε να μη μισθωθεί ποτέ σε πελάτη. Σε αυτό το παράδειγμα το pool είναι 10.180.7.0/24, ο διακομιστής κρατά το 10.180.7.1 και οι μισθώσεις ξεκινούν από το 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Το πρόθεμα του pool και ο resolver μοιράζονται ένα υποδίκτυο, οπότε η διαδρομή που μεταφέρει ήδη την κίνηση του tunnel μεταφέρει και τα ερωτήματα. Ακριβώς αυτή η μία ιδιότητα κάνει τη διόρθωση φορητή σε όλους τους πελάτες. Σε μια διαμόρφωση swanctl τα ίδια δύο γεγονότα εμφανίζονται ως ορισμός pool και ρύθμιση DNS στη σύνδεση αντί για σύνταξη ipsec.conf.

Ο διακομιστής δεν χρειάζεται νέα φυσική διεπαφή για αυτό. Η προσθήκη του 10.180.7.1 στη διεπαφή loopback αρκεί για να δεσμευτεί και να απαντήσει ένας resolver, αφού οι πελάτες τον φτάνουν μέσω της διαδρομής του pool που υπάρχει ήδη. Κρατήστε τη διεύθυνση έξω από το εύρος μίσθωσης ώστε κανένας πελάτης να μην τη διεκδικήσει κατά λάθος. Αν το pool διαχειρίζεται από εξωτερική υπηρεσία DHCP ή RADIUS, δεσμεύστε τη διεύθυνση και εκεί, αλλιώς ο πρώτος πελάτης που θα ρωτήσει θα την πάρει.

Δεσμεύστε τον resolver και κλείστε τη θύρα 53

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Αυτό το απόσπασμα unbound δέχεται ερωτήματα από το pool του tunnel και αρνείται όλα τα άλλα, που είναι η πολιτική που θέλουν οι περισσότεροι εταιρικοί resolvers. Αν το ίδιο στιγμιότυπο απαντά και σε πελάτες LAN, προσθέστε το πρόθεμα LAN ρητά αντί να διευρύνετε τον ακροατή σε όλες τις πηγές.

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

Επαληθεύστε τι έλαβε πραγματικά ο πελάτης

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Το άμεσο ερώτημα αποδεικνύει ότι ο resolver απαντά στη διεύθυνση του pool από host που μπορεί να τον φτάσει. Δεν αποδεικνύει ότι το Mac επέλεξε αυτόν τον διακομιστή. Στο macOS, το scutil --dns απαριθμεί resolvers ανά περιορισμένη υπηρεσία και είναι πιο διαφωτιστικό από τον πίνακα σύνοψης· στα Windows, το Get-DnsClientServerAddress δείχνει αν ο προσαρμογέας του tunnel δέχτηκε την τιμή που στάλθηκε.

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