Ονόματα πελατών OpenVPN στο dnsmasq: σενάριο ή στατικές εγγραφές;

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

Αποφασίστε ανά όνομα, όχι ανά πύλη

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

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

Η δυναμική διαδρομή: learn-address και η δεξαμενή

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

client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.sh

Το learn-address εκτελεί το σενάριό σας κάθε φορά που μια διεύθυνση προστίθεται, ενημερώνεται ή διαγράφεται, και περνά τη λειτουργία, τη διεύθυνση και το κοινό όνομα. Ένα ελάχιστο σενάριο προσθέτει μία γραμμή ανά πελάτη και την αφαιρεί κατά τη διαγραφή:

#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
  add|update) echo "$2 $3" >> "$HOSTS" ;;
  delete)     sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)

Σε συσκευή tun το δεύτερο όρισμα είναι η διεύθυνση σήραγγας του πελάτη, οπότε η γραμμή είναι άμεσα χρησιμοποιήσιμη. Σε συσκευή tap το OpenVPN περνά αντ' αυτού τη διεύθυνση MAC του πελάτη, γιατί ένα τμήμα tap μπορεί να μεταφέρει και άλλα πρωτόκολλα εκτός από IPv4, και τότε πρέπει να αναζητήσετε τη διεύθυνση στο αρχείο δεξαμενής με το κοινό όνομα πριν γράψετε οτιδήποτε.

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

Η στατική διαδρομή: address= και επέκταση τομέα

Στρέψτε το dnsmasq στο παραγόμενο αρχείο αντί για το αρχείο hosts του συστήματος, και δώστε του έναν τομέα ώστε τα σύντομα ονόματα να επεκτείνονται σε πλήρως πιστοποιημένα:

domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces

Με το domain ρυθμισμένο, μια γραμμή όπως η 10.8.0.6 alice απαντά και για το alice και για το alice.corp.example. Περιορίστε το listen-address στην πύλη της σήραγγας και στο loopback, γιατί ένας resolver που δημοσιεύεται κατά λάθος στη διεπαφή LAN είναι υπηρεσία που δεν σκοπεύατε να προσφέρετε.

Οι υπηρεσίες που δεν προέρχονται ποτέ από τη δεξαμενή παίρνουν δικές τους εγγραφές. Βάλτε τις σε ξεχωριστό αρχείο drop-in στον κατάλογο ρυθμίσεων της διανομής, ώστε μια αναβάθμιση πακέτου να μην μπορεί να τις αντικαταστήσει:

address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5

Παραδώστε τον resolver, αλλιώς δεν γίνεται τίποτα

Ένας resolver που κανείς δεν ρωτά δεν αλλάζει τίποτα. Ο διακομιστής πρέπει να τον διαφημίσει:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Οι πελάτες Windows εφαρμόζουν και τις δύο επιλογές μόνοι τους. Οι περισσότεροι πελάτες Linux όχι: χρειάζονται υποστηριζόμενη ενσωμάτωση resolver, όπως το άγκιστρο update-resolv-conf της διανομής ή τη διαχείριση DNS του NetworkManager, ή χειροκίνητο τομέα αναζήτησης και διακομιστή ονομάτων. Ελέγξτε τον πραγματικό resolver του πελάτη αντί να υποθέσετε ότι το push τηρήθηκε, γιατί ένα push που αγνοείται μοιάζει ακριβώς με διακομιστή που δεν απαντά.

Επαληθεύστε σε τρία επίπεδα

Ρωτήστε πρώτα απευθείας τον διακομιστή, μετά έναν πελάτη και μετά την εφαρμογή:

dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example

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

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